# openstatus — full content
> Openstatus is an open-source uptime monitoring and status page platform built for infra as code: monitors, status pages, and notification channels are declared in YAML or Terraform and driven from a CLI, a typed API, or an MCP server (Claude, ChatGPT, Cursor), so your agents can update them. It runs synthetic checks in parallel from 28 regions across Fly.io, Koyeb, and Railway and surfaces incidents on branded status pages. Available as managed SaaS or self-hosted (AGPL-3.0). Bootstrapped, founded in 2023. Blog posts, changelog entries, guides, use cases, and comparisons live in [llms.txt](https://www.openstatus.dev/llms.txt) as links — not inlined here.
## Who it's for
- Teams that manage uptime monitoring and status pages as infra as code and let agents (Claude, Cursor, ChatGPT, CI) open and resolve incidents over MCP, CLI, or API
- Development teams that want transparent incident communication
- Companies that need multi-region uptime monitoring
- Teams that prefer infrastructure-as-code workflows (YAML via the CLI, or the Terraform provider)
- Organizations that require self-hosted monitoring behind a firewall (private locations)
- Open-source projects and startups looking for a free or affordable monitoring solution
## Pricing
- **Hobby** — $0/month: 1 monitor, 6 regions, 10m check interval, 1 status page, 3 page components, 14-day data retention
- **Starter** — $30/month: 20 monitors, 28 regions, 1m check interval, 1 status page, 20 components, 3-month retention, subscribers, custom domain, WhatsApp/PagerDuty alerts
- **Pro** — $100/month: 50 monitors, 28 regions, 30s check interval, 5 status pages, 50 components, 12-month retention, private locations, OTel exporter, 20 notification channels
- **Scale** — $500/month: everything in Pro plus 10 status pages, 500 page components, and White Label, Magic Link auth, and IP Restriction included at no extra cost
Annual billing gives 2 months free (Starter $300/yr, Pro $1,000/yr, Scale $5,000/yr). Pricing is available in USD and EUR.
## Key Features
- **28-region monitoring** — Parallel checks across Europe, North America, South America, Asia, Africa, and Oceania; no round-robin, all selected regions fire simultaneously
- **Multi-cloud** — Monitors run on Fly.io, Koyeb, and Railway for true cloud diversity
- **Status Pages** — Branded public or password-protected pages with custom domains, themes, maintenance windows, and subscriber notifications (email, RSS, Slack)
- **API Monitoring** — Assertions, thresholds, status code checks, header and body validation
- **Infra as Code** — Define monitors, status pages, and notification channels in YAML (CLI, GitHub Actions) or Terraform
- **Private Locations** — 8.5MB Docker image for monitoring internal services behind firewalls
- **Alerting** — Email, Slack, Discord, webhook, WhatsApp, PagerDuty, OpsGenie, Grafana OnCall
- **OpenTelemetry** — Export synthetic check metrics to any OTLP endpoint
- **SDK** — Node.js SDK on JSR (@openstatus/sdk-node)
- **MCP server** — Streamable-HTTP MCP at https://api.openstatus.dev/mcp with OAuth 2.1, for status reports, maintenance windows, and monitor reads; every mutation lands in the audit log
- **Open-source** — AGPL-3.0-licensed, self-hostable, 9k+ GitHub stars
## Key Differentiators
- Built for humans and agents: MCP server, --json CLI output, typed API, read-only or read-write API key scopes
- Open-source and bootstrapped (no VC funding)
- Parallel scheduling — all selected regions check simultaneously (vs. round-robin competitors)
- Unlimited team members on paid plans
- Status page subscribers included (not a paid add-on)
- Private status pages included in the team plan (not an additional charge)
- Self-hosting option with full feature parity
---
---
title: "Free & Open Source Status Page and Uptime Monitoring"
date: Apr 07, 2026
author: "openstatus"
description: "Open source status page and uptime monitoring. Your monitors update it, your subscribers hear it first, your auditor gets the trail. Live in five minutes."
category: "product"
---
[Get started free](https://app.openstatus.dev)
[GitHub 9k+](/github)
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.
A live status page for the fictional Pied Piper, mid-incident: a Degraded Performance banner, Checkout API degraded at 99.94% uptime, Webhooks, Dashboard and Docs operational, each with a 45-day uptime bar.
## Trusted by teams who ship transparency
[Cal.com](https://status.cal.com), [Twenty](/customers/twenty), [Documenso](https://status.documenso.com), [Traefik](/customers/traefik), [Passbolt](https://passboltuptime.com), [Hanko](https://status.hanko.io), [WhiteBIT](https://status.whitebit.com), [Superwall](https://status.superwall.com), [OpenPanel](https://status.openpanel.dev), [Probo](https://probostatus.com), [Roundtable](https://roundtable.eu), [Smplrspace](https://status.smplrspace.com)
## One incident, start to finish
At 09:41 the Checkout API at Pied Piper starts returning 503s from Europe. Here is what openstatus does before the team has finished reading the first alert, and what is left behind six months later.
## Your monitor catches it first
Four of the six regions the monitor runs from confirm the 503s, so the alert fires before the first support ticket arrives. It lands in Slack and PagerDuty with a link to the failing checks.
- [Uptime monitoring](/uptime-monitoring)
- [Notification channels](/docs/reference/notification)
- [Check any URL from 28 regions](/play/checker)
The Slack alert at 09:41: Checkout API returned 503 from lhr, ams, cdg and koyeb_fra at 4,388 ms, with 4 of 6 regions failing the status-code assertion.
## Know what to say before you say it
Response logs for the 09:41 check, one row per region: the four European regions returned 503 in about 4 seconds, almost all of it TTFB, while Virginia and San Jose returned 200 in about 230 ms.
Open the failing checks. The European regions spend four seconds waiting on the edge while DNS and TLS are fine, and the US regions return 200 in under 250 ms. That is the sentence the status report needs, and the headers and body are kept in case the postmortem needs more.
- [Response logs and retention](/docs/concept/response-logs-and-retention)
- [Request phases: DNS, TCP, TLS, TTFB](/docs/concept/latency-vs-response-time#the-request-in-phases-dns-tcp-tls-ttfb-transfer)
## Declare the incident, get a channel
One slash command declares the incident with a title and a severity. Openstatus opens a dedicated Slack channel, invites you and pins the incident card, so the response has one place to happen.
- [Incident management](/incident-management)
- [Slack agent](/docs/guides/how-to-setup-slack-agent)
Gilfoyle runs `/openstatus incident declare Checkout API 503s in EU --sev major` in #incidents at 09:43. The openstatus app posts an approval card, confirms the incident is declared and opens a dedicated incident channel.
## Tell customers from Slack, or with your favorite agent
An engineer asks @openstatus in the incident thread to open a status report. The agent drafts "Elevated errors on Checkout API", the engineer approves, and 1,337 subscribers are notified.
Ask the openstatus agent in the incident thread. It drafts the status report, you approve it, and it goes live without anyone opening the dashboard. The same agent runs wherever you work: connect the MCP server to Claude, ChatGPT or Cursor and publish it from there.
- [Slack agent](/docs/guides/how-to-setup-slack-agent)
- [MCP server](/tooling/mcp-server)
- [CLI](/tooling/cli)
- [API](/tooling/api)
## Everyone hears it from you first
Subscribers get the update by email, RSS and Slack Connect the moment it is approved. Support stops answering "is it down?" because the answer is already in the inbox.
- [Subscriptions](/docs/reference/subscriber)
- [Reducing support tickets](/use-case/reduce-support-tickets)
The 09:52 Identified update as it lands in a customer's Slack Connect channel, with the delivery summary: 1,337 emails sent, RSS and Atom updated, 3 Slack Connect workspaces notified.
## Only the right people see it
Two pages side by side: the public status.piedpiper.dev shows Checkout API degraded, while internal.piedpiper.dev asks for a password and only admits the 203.0.113.0/24 range.
The public page shows the Checkout API as degraded. The internal page, behind a password and the office IP range, shows the failing regions and the rollback progress.
- [Status page](/status-page)
- [Password, magic link and IP restriction](/docs/reference/status-page#password-basic-auth)
- [Status pages for enterprise sales](/use-case/enterprise-sales)
## Update the status where the work happens
When the rollback lands, mark the incident mitigated from its channel. The internal status and the public status report move separately, so the team says "mitigated" while customers read "monitoring".
- [Incident management](/incident-management#internal-status-public-update)
- [Status report reference](/docs/reference/status-report)
At 10:14 Gilfoyle runs `/openstatus incident mitigate Rollback complete in eu-west-1 and eu-west-2.` in the incident channel and the app confirms the incident is now mitigated. The linked status report "Elevated errors on Checkout API" reads Monitoring, with 1,337 subscribers notified.
## The postmortem arrives as a draft
The postmortem draft, written by the agent at 11:02: summary, impact (55m, from 09:41 to 10:36 UTC, Europe only), a UTC timeline, root cause (the 09:38 edge config deploy), what went well, what went wrong and two action items, with buttons to approve it or draft again.
Once the incident is resolved, the agent drafts a blameless postmortem from the timeline, the public updates and the channel history. You edit it, approve it and close the incident while everyone still remembers what happened.
- [Incident management](/incident-management#a-postmortem-with-a-first-draft)
- [MCP server](/tooling/mcp-server)
## The trail exists when the auditor asks
Every step is logged: who declared it, from where, when each update shipped. When SOC 2 asks how you notify customers during an incident, you send one link.
- [Status pages for compliance](/use-case/compliance)
The incident's audit log, with the newest entry at the top. From oldest to newest: monitor.alert at 09:41:12, incident.create at 09:43:08 and status_report.create at 09:44:30 by gilfoyle@piedpiper.dev via Slack, notification.send a second later, then the identified, monitoring and resolved updates, the incident mitigated and resolved, and the postmortem approved at 11:20:48. It exports as CSV or JSON.
The same incident six months later in the status page's events feed: four timestamped updates from investigating at 09:44 to resolved at 10:36.
## In their words
> “Open-source CRM needs an open-source status page. Openstatus took us minutes to set up — and it covers everything our customers actually depend on.”
>
> — Félix Malfait, Co-founder @twentycrm · [Read the story](/customers/twenty)
> “We picked openstatus because the workflow matched ours. We stayed because it keeps matching.”
>
> — Michel Loiseleur, Head of Platforms @traefiklabs · [Read the story](/customers/traefik)
## For humans and agents
Every action in the dashboard is reachable programmatically. One API key, four ways in.
- [CLI](/tooling/cli) for the terminal and CI, with `--json` output for scripts.
- [API](/tooling/api) with typed endpoints, an OpenAPI spec and a Node SDK.
- [MCP server](/tooling/mcp-server) so Claude, ChatGPT or Cursor can run it for you.
- [Terraform](/tooling/terraform) to keep monitors, status pages and notifications as HCL.
## Flat pricing
No per-seat fees. Every new workspace starts with a 14-day Starter trial, no card needed. [Open source](/github) and self-hostable under AGPL-3.0.
| Plan | Price | Includes |
| --- | --- | --- |
| Hobby | $0 | 1 monitor, 1 status page, checks every 10 min |
| Starter | $30/mo | 20 monitors, 1-min checks, custom domain, subscribers |
| Pro | $100/mo | 50 monitors, 30-sec checks, all 28 regions, custom theme |
| Scale | $500/mo | 500 components, white label, email auth and IP restriction |
## Get started
[Create your status page](https://app.openstatus.dev)
[Full pricing](/pricing)
No account yet? [Check any URL's response time from 28 regions](/play/checker), no sign-up needed.
## Frequently asked questions
What is openstatus?
Openstatus is an open-source status page and uptime monitoring platform. Monitor from 28 regions, publish a branded status page on your own domain, and manage it from the dashboard, Slack, [CLI](/tooling/cli), [API](/tooling/api), [Terraform](/tooling/terraform) or an [AI agent](/tooling/mcp-server).
It is used by teams like [Cal.com](https://status.cal.com), [WhiteBIT](https://status.whitebit.com), and [Documenso](https://status.documenso.com), and available as a [managed service](https://app.openstatus.dev) or for [self-hosting](/github).
What does the free plan include?
The free Hobby plan includes **one monitor**, **one status page** (with three page components), and a minimum check interval of `10m`. See the [pricing page](/pricing) for a full comparison.
No credit card required. Upgrade or cancel at any time.
Do I need a status page for SOC 2?
SOC 2's CC2.3 criteria asks you to demonstrate incident communication with external parties. A public status page with **timestamped**, audited incident history is the shortest answer.
Every status report on openstatus is timestamped and documented automatically, and every mutation is written to the audit log. Read more about [SOC 2 status pages](/use-case/compliance).
Can I self-host openstatus?
Yes. Openstatus is AGPL-3.0 and can be self-hosted with Docker. You can also keep the hosted version and run **private monitoring locations** behind your firewall for internal services.
- [Self-hosting the full openstatus stack](/docs/guides/self-hosting-openstatus)
- [Self-hosting the status page only](/docs/guides/self-host-status-page-only)
The source code is on [GitHub](/github).
Who is behind openstatus?
Openstatus is built by [Thibault](https://bsky.app/profile/thibaultleouay.dev) and [Max](https://x.com/mxkaske), a bootstrapped two-person team building in public.
We're profitable and self-funded, and we'll be here when your next audit comes around. Read more on [our about page](/about).
---
---
title: "Incident Management"
date: Oct 05, 2026
author: "Maximilian Kaske"
description: "Declare an incident from Slack or the dashboard, run it in its own channel, keep one timeline and leave with a postmortem. Next to the monitors and the status page it belongs to."
category: "Product"
---
[Declare your first incident](https://app.openstatus.dev)
[Set up the Slack agent](/docs/guides/how-to-setup-slack-agent)
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.
The incident page for "Checkout API 503s in EU" at the fictional Pied Piper: severity Major, status Resolved, commander Gilfoyle, duration 55m, and a timeline from Declared at 09:43 through a note pinned in Slack, the linked status report, Mitigated at 10:14 and Resolved at 10:36 to the approved postmortem at 11:20.
## Trusted by teams who ship transparency
[Cal.com](https://status.cal.com), [Twenty](/customers/twenty), [Documenso](https://status.documenso.com), [Traefik](/customers/traefik), [Passbolt](https://passboltuptime.com), [Hanko](https://status.hanko.io), [WhiteBIT](https://status.whitebit.com), [Superwall](https://status.superwall.com), [OpenPanel](https://status.openpanel.dev), [Probo](https://probostatus.com), [Roundtable](https://roundtable.eu), [Smplrspace](https://status.smplrspace.com)
## Why run incidents here
**It starts where the alert lands**
The monitor that caught the failure, the incident and the status page live in one workspace. Nothing is copied between tools while the Checkout API is down.
**Internal and public stay apart**
The team works with severities, notes and a commander. Customers read a [status report](/status-page) in your words. The two are linked, never mixed.
**The record writes itself**
Every status change, note and public update is timestamped as it happens. The postmortem and the [audit trail](/use-case/compliance) are built from it, not from memory.
## Declare from Slack or the dashboard
Run `/openstatus incident declare` with a title and a severity, approve the card, and the incident exists. The dashboard has the same form, with a commander, a start time you can set in the past and an open status report to link.
- [Set up the Slack agent](/docs/guides/how-to-setup-slack-agent)
- [Status report reference](/docs/reference/status-report)
Gilfoyle runs `/openstatus incident declare Checkout API 503s in EU --sev major` in #incidents at 09:43. The openstatus app posts an approval card with the title and severity, then confirms the incident is declared and that a dedicated channel was opened with Gilfoyle invited.
## A Slack channel per incident
The incident's own Slack channel, named inc-, the date and checkout-api-503s-in-eu. The pinned card shows severity Major and status Open. Gilfoyle's 09:49 message, "Edge config deploy at 09:38 changed EU routing. Rolling back.", carries a pin reaction and a check mark from the app: it is now a note on the timeline. A reminder follows after 4 hours without an update.
Every incident gets a channel with the severity and status in its topic and the incident card pinned on top. React to any message with 📌 and it becomes a timeline note, with a link back to Slack.
If the incident goes quiet, the channel gets a reminder: after one hour for critical, four for major and a day for minor.
- [Slack agent](/docs/guides/how-to-setup-slack-agent)
- [Notification channels](/docs/reference/notification)
## From the monitor that caught it
When a monitor goes down, declare the incident from its downtime row and the start time is already filled in. The duration counts from when the impact began, not from when someone got around to declaring it.
- [Uptime monitoring](/uptime-monitoring)
- [Response logs and retention](/docs/concept/response-logs-and-retention)
The Slack alert that started it at 09:41: Checkout API returned 503 from lhr, ams, cdg and koyeb_fra at 4,388 ms, with 4 of 6 regions failing the status-code assertion.
## Internal status, public update
At 10:14 Gilfoyle runs `/openstatus incident mitigate Rollback complete in eu-west-1 and eu-west-2.` in the incident channel and the app confirms the incident is now mitigated. Below it, the linked status report "Elevated errors on Checkout API" reads Monitoring, with its own public message and 1,337 subscribers notified.
Mitigate, resolve, cancel or reopen from the channel or the dashboard, with a note that lands on the timeline. The linked status report keeps its own status and wording, and you post the public update from the same page.
- [Status page](/status-page)
- [Subscriptions](/docs/reference/subscriber)
## A postmortem with a first draft
Once the incident is resolved, the agent drafts a blameless postmortem from the timeline, the public updates and the channel history. Where it has no facts it says so instead of guessing.
Edit it in markdown, approve it, and close the incident.
- [Slack agent](/docs/guides/how-to-setup-slack-agent)
- [Status pages for compliance](/use-case/compliance)
The postmortem draft, written by the agent, in seven sections: summary, impact (55m, from 09:41 to 10:36 UTC, Europe only), a UTC timeline from Declared to Resolved, root cause (the 09:38 edge config deploy), what went well, what went wrong, and two action items as a checklist. Buttons to approve it or draft again with the agent.
## For agents, with a paper trail
The audit log for the same incident, with the newest entry at the top. From oldest to newest: monitor.alert at 09:41:12, incident.create at 09:43:08 by gilfoyle@piedpiper.dev via Slack, the status report and its updates, incident.update to mitigated and resolved, and the postmortem created by the agent and approved at 11:20:48.
The MCP server and the Slack agent share the incident tools: declare, update, change status, add a note, draft the postmortem. Anything that changes state asks for approval first.
Every one of those steps is in the audit log with the person behind it, whichever surface they used.
- [MCP server](/tooling/mcp-server)
- [Connect openstatus to your agent](/docs/guides/how-to-connect-openstatus-to-your-agent)
## Get started
[Declare your first incident](https://app.openstatus.dev)
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.
## Frequently asked questions
What is incident management?
Incident management is how a team responds when something breaks: someone declares the incident, one person takes command, the team works the problem in one place, customers are kept informed, and afterwards a postmortem records what happened and what changes. Openstatus keeps the declaration, the timeline, the public status report and the postmortem in one record.
What is the difference between an incident and a status report?
An incident is internal: severity, commander, timeline notes and the postmortem are for your team. A status report is public: it is what customers read on your status page and receive as a subscriber. You link the two, and each keeps its own status, so the team can mark an incident mitigated while the status report still says monitoring.
Do I need Slack to manage incidents?
No. You can declare, update, resolve and write the postmortem from the dashboard. Connecting Slack adds the channel per incident, slash commands, pinning messages to the timeline, stale-incident reminders and agent drafting.
How does the postmortem draft work?
Once an incident is resolved, the agent drafts a blameless postmortem from the incident's fields, its timeline, the public status report updates and the history of the incident's Slack channel. The draft has seven sections: summary, impact, timeline, root cause, what went well, what went wrong and action items. Where it has no facts it says what is unknown. You edit the draft, approve it and close the incident.
Which severities and statuses are there?
Three severities: critical for a major outage or data loss, major for significant degradation, and minor for limited impact. An incident is open, mitigated, resolved or canceled. Closing an incident freezes it: status, severity, commander and notes can no longer change.
Can an AI agent run an incident?
Yes. The MCP server and the Slack agent share the same incident tools: declare, update, change status, add a note, draft and approve the postmortem. Every action that changes something asks for approval first and is written to the audit log with the person behind it.
---
---
title: "Status Page"
date: Nov 10, 2025
author: "Maximilian Kaske"
description: "Create a public or private status page in minutes. Show real-time uptime, incidents and maintenance on a fully branded page with a custom domain."
category: "Product"
---
[Create your status page](https://app.openstatus.dev)
[Theme explorer](https://themes.openstatus.dev)
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.
Pied Piper's status page during a degraded Checkout API, built from the real status-page blocks: grouped components with 45-day uptime bars and a Get updates menu offering Email, Slack, RSS, JSON and SSH.
## Trusted by teams who ship transparency
[Cal.com](https://status.cal.com), [Twenty](/customers/twenty), [Documenso](https://status.documenso.com), [Traefik](/customers/traefik), [Passbolt](https://passboltuptime.com), [Hanko](https://status.hanko.io), [WhiteBIT](https://status.whitebit.com), [Superwall](https://status.superwall.com), [OpenPanel](https://status.openpanel.dev), [Probo](https://probostatus.com), [Roundtable](https://roundtable.eu), [Smplrspace](https://status.smplrspace.com)
## Why you need one
**It deflects support load**
During an outage every user asks the same question. A status page answers it once, for everyone, while your team fixes the thing. See [reducing support tickets](/use-case/reduce-support-tickets).
**Enterprise buyers ask for one**
Security questionnaires ask how you notify customers during an incident. A public URL with a year of history is the strongest answer. See [status pages for enterprise sales](/use-case/enterprise-sales).
**Auditors want the evidence**
SOC 2 CC2.3 asks you to prove external communication. Every report is timestamped and archived, so the trail exists before they ask. See [status pages for compliance](/use-case/compliance).
## Components, groups and external services
Attach monitors and the uptime fills in from your checks. Add the services you depend on but do not run, and group everything the way your customers think about it.
- [Page components reference](/docs/reference/page-components)
- [Status page reference](/docs/reference/status-page)
The components list: Checkout API, Webhooks, Dashboard and Docs synced from monitors, Stripe set by hand as an external service, grouped into Payments and Platform. A group takes the worst status of its members.
## Subscriptions
The Get updates popover with 1,337 email subscribers: an email form, the RSS URL for Slack's feed app, RSS and Atom URLs, the JSON feed at status.piedpiper.dev/feed/json and the SSH command.
Users subscribe once and get every status report and maintenance by email, RSS, Atom or JSON. Teams pull the same feed into Slack.
- [All subscription methods](/docs/reference/subscriber)
- [Slack Connect updates](/guides/slack-status-page-subscriptions)
## Translations
Set a default locale and turn on the switcher. The page chrome and the canonical status copy are translated; your updates stay in the language you wrote them.
English, French, German, Turkish, Hindi, Korean and Japanese today, with more from community contributions.
- [Translate your status page](/docs/guides/how-to-translate-status-page)
The same page in French: a "Performances dégradées" banner, components labelled Opérationnel or Dégradé, and a switcher offering English, Deutsch, Français and 日本語.
## Slack agent
The Slack thread where @openstatus drafts "Elevated errors on Checkout API" with Approve, Approve & notify and Cancel buttons, then confirms it is live on status.piedpiper.dev.
Mention @openstatus in any thread. It drafts the report, you approve, it publishes. Follow up in the same thread with "it's fixed" and it drafts the next update.
Every action asks for confirmation before anything goes public, and every action is written to the audit log.
- [Set up the Slack agent](/docs/guides/how-to-setup-slack-agent)
## Branded, on your domain
Pick a theme from the store or override any CSS variable, separately for light and dark. Point status.yourdomain.com at it, and even white label it to drop the "Powered by" line.
- [Theme Store](https://themes.openstatus.dev)
- [Custom theme variables](/docs/reference/status-page#custom-theme)
The same status blocks re-skinned with a Theme Store theme: banner, component and uptime bar follow its CSS variables such as --success, --warning and --radius, in light and dark.
## Internal and private pages
Public and internal pages side by side: the public one lists all four components, the internal one shows a password prompt with an IP allowlist of 203.0.113.0/24 switched on.
Public by default. Protect a page with a password, magic-link login, or a CIDR allowlist so internal teams and named clients see more than the public does.
- [Password, magic link and IP restriction](/docs/reference/status-page#password-basic-auth)
- [Status pages for enterprise sales](/use-case/enterprise-sales)
## Maintenance windows
Schedule the window ahead of time. Subscribers are told when it is planned, the banner flips to maintenance while it runs, and affected components stop counting against uptime.
- [Maintenance reference](/docs/reference/maintenance)
A scheduled maintenance banner, "Database upgrade": a two-hour window three days out affecting Checkout API and Webhooks, with 1,337 subscribers notified when it was scheduled.
## Import from another provider
The import preview for Atlassian Statuspage: 5 components, 2 groups, 37 status reports, 3 maintenances, 1,337 subscribers and 4 monitors, shown before anything is written.
Paste an API key from Atlassian Statuspage, Better Stack or Instatus. Preview components, incidents, maintenances and subscribers before anything is written.
- [Import guide](/docs/guides/how-to-import-status-page)
## For terminals and agents
The same page over SSH for people in a terminal, and as markdown for the agents and LLMs your customers point at it. No screenshots, no scraping.
- [SSH command](/docs/reference/status-page#ssh-command)
- [Shadcn component registry](/registry)
The page over SSH, `ssh pied-piper@ssh.openstatus.dev`, printing "Degraded Performance · Pied Piper Status · 5 components · 1 degraded", and the same page as markdown with a 30-day bar of + and ~ characters.
## Get started
[Create your status page](https://app.openstatus.dev)
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.
## Frequently asked questions
What is a status page?
A status page is a dedicated webpage where companies communicate the real-time health of their services to users. It shows which systems are operational, degraded, or experiencing outages, and provides timestamped incident updates. Status pages reduce support tickets during incidents, build user trust through transparency, and satisfy compliance requirements like SOC 2.
When should I use a public vs private status page?
A public status page is customer-facing and indexed — it deflects support tickets and answers vendor questionnaires. A private (internal) status page is for staff, contractors, or a single client, with access controlled by password protection, magic link authentication, or an IP allowlist. You can run both from the same workspace.
What's the difference between monitors and external services in page components?
Monitors are automatically synced with your openstatus uptime monitoring data and update in real-time. External services are manually managed components for third-party dependencies or systems you don't directly monitor but want to report status for.
Can I translate my status page into other languages?
Yes, status pages support multiple languages (currently English, French, German, Turkish, Hindi, Korean, and Japanese). You can set a default locale and enable a locale switcher so visitors choose their preferred language. Translations are open source — you can contribute new languages by adding a locale to the shared registry and running the dev server to generate the translation file.
Can I use my own domain for the status page?
Yes, you can configure custom domains to host your status page on your own domain (e.g., status.yourcompany.com) instead of the default openstatus subdomain. This keeps the experience consistent with your brand.
How do status page subscriptions work?
Users can subscribe to receive updates when you post status reports or maintenance notices. We support email notifications, RSS/Atom feeds for feed readers, and JSON feeds for programmatic consumption. Subscribers are automatically notified when you publish updates.
Can I customize the appearance of my status page?
Yes. Pick a community theme from the Theme Store or contribute your own. For a private look, the Custom Theme editor lets you override any CSS variable of the base theme for light and dark mode — included on Pro and Scale, or a $20/mo add-on on Starter. You can also define which data to share (uptime percentages, response times, or manual reports only).
How do I create a status page?
Sign up, create a status page, give it a name and a slug, then add page components — either monitors synced from your uptime monitoring or external services you manage by hand. Point a custom domain at it if you want status.yourcompany.com, pick a theme, and publish. Most teams are live in under ten minutes on the free plan.
How much does a status page cost?
The free Hobby plan includes one status page with three components and no credit card. Paid plans start at $30/month for Starter (one status page, 20 components, custom domain, subscribers), $100/month for Pro, and $500/month for Scale. Annual billing gives you two months free. Extra status pages are $20/month each.
What is the Slack agent and what can it do?
The Slack agent lets you manage your status page directly from Slack using natural language. @mention @openstatus in any channel or thread to create incidents, post updates, and resolve reports — without leaving Slack. No slash commands required.
---
---
title: "Uptime Monitoring"
date: Nov 10, 2025
author: "Thibault Le Ouay Ducasse"
description: "Monitor your websites, APIs and services from 28 regions. Get alerted the moment a check fails an assertion or exceeds your threshold."
category: "Product"
---
[Create your monitor](https://app.openstatus.dev)
[Global speed checker](/play/checker)
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.
The monitor overview for Checkout API, checked every minute: 99.94% uptime, 4 of 6 regions failing, P50 231 ms, P95 4.39 s, with an uptime chart per minute and a P95 latency chart stacked by phase where TTFB jumps to about 4 seconds.
## Trusted by teams who ship reliability
[Cal.com](https://status.cal.com), [Twenty](/customers/twenty), [Documenso](https://status.documenso.com), [Traefik](/customers/traefik), [Passbolt](https://passboltuptime.com), [Hanko](https://status.hanko.io), [WhiteBIT](https://status.whitebit.com), [Superwall](https://status.superwall.com), [OpenPanel](https://status.openpanel.dev), [Probo](https://probostatus.com), [Roundtable](https://roundtable.eu), [Smplrspace](https://status.smplrspace.com)
## How it works
**1. Declare**
URL, method, headers, body and schedule. In the dashboard, the CLI or Terraform.
**2. Probe**
Checkers in 28 regions run the request and record status, timing and body.
**3. Assert**
Status code, headers, body and latency thresholds decide success, degraded or failed.
**4. Alert and publish**
Notify Slack, PagerDuty or email. The status page reflects it without manual work.
## 28 regions, three clouds
Probes run on Fly.io, Koyeb and Railway, so a provider incident never blinds you. Pick the regions your customers are in and see latency per region, not an average.
- [Check any URL from every region](/play/checker)
Per-region latency for the last check: London 4,388 ms, Amsterdam 4,102 ms, Paris 4,051 ms and Frankfurt 3,970 ms, all 503; Virginia 231 ms and San Jose 244 ms, both 200. 6 of the 28 regions are selected.
## API monitoring with assertions
The request configuration and last result: a Bearer authorization header, assertions on status code 200 (failed, got 503), content-type contains json (passed) and body contains session_id (failed), degraded at 1,000 ms and timeout at 5,000 ms.
Any method, custom headers, a request body. Assert on status code, header and body, and set degraded and timeout thresholds so slow counts as a problem before down does.
- [HTTP monitor reference](/docs/reference/http-monitor)
## Alerts where you already are
A failed assertion from one region is noise; from half your regions it is an alert. Route it to Slack, Discord, PagerDuty, Opsgenie, email, SMS or a webhook, with the failing requests attached.
Telegram, Google Chat, Microsoft Teams, WhatsApp, Grafana OnCall and ntfy are there too.
- [Notification channels](/docs/reference/notification)
The alert as it reaches Slack, PagerDuty, email and a webhook: "Checkout API is failing", 503 Service Unavailable from four regions, "Expected status code 200, received 503", with a link to the failing checks.
## Where the time went
The phase breakdown of the London check: DNS 12 ms, Connect 38 ms, TLS 61 ms, TTFB 4,265 ms, Transfer 12 ms. Only TTFB is above the 1,000 ms degraded threshold.
Every check records DNS, connect, TLS, time to first byte and transfer separately. A slow origin and a slow certificate handshake look the same in a total; they do not look the same here.
- [Export every request to your OTLP endpoint](/docs/guides/how-to-export-metrics-to-otlp-endpoint)
## Monitoring as code
Declare monitors in HCL with the Terraform provider, or from the CLI in CI. Monitor changes get code-reviewed in the PR that ships the service they watch.
Already have monitors in the dashboard? Run `openstatus terraform generate` to bootstrap an HCL file from your workspace.
- [Terraform provider](/tooling/terraform)
- [CLI](/tooling/cli)
```terraform
resource "openstatus_http_monitor" "checkout" {
name = "Checkout API"
url = "https://api.piedpiper.dev/v1/checkout"
method = "POST"
periodicity = "1m"
regions = ["fly-lhr", "fly-ams", "koyeb-fra", "fly-iad"]
status_code_assertions {
target = 200
comparator = "eq"
}
degraded_at = 1000
timeout = 5000
}
```
## Private locations
The docker run command that starts a probe from ghcr.io/openstatushq/private-location, an 8.5 MB image for arm64 and amd64, and two probes online: vpc-eu-west at 10.0.4.12 and office-berlin at 192.168.1.40.
Some services are not reachable from the internet. Run the probe in your VPC or office network with one container; results land in the same dashboard and status page. The probe dials out, so no inbound firewall rule is needed.
- [Private location docs](/docs/guides/how-to-create-private-location)
- [Cloudflare Containers guide](/docs/guides/how-to-deploy-probes-cloudflare-containers)
- [Raspberry Pi deployment](/blog/deploy-private-locations-raspberry-pi)
## Every request, kept
Response logs with the timing breakdown, headers and body per region, for as long as your plan retains data.
- [Response logs and retention](/docs/concept/response-logs-and-retention)
The response-logs table for the check, one row per region with status, latency and a DNS, connect, TLS, TTFB and transfer bar. Headers and body are kept for every failed check and every request can be exported to OTLP.
## Get started
[Create your monitor](https://app.openstatus.dev)
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.
## Frequently asked questions
What is uptime monitoring?
Uptime monitoring is the practice of checking, on a fixed schedule and from outside your own network, whether a service is reachable and responding correctly. Checks typically run every 30 seconds to 10 minutes from probe locations around the world. Because the checks originate externally, they catch failures your internal dashboards cannot see — DNS problems, expired certificates, and regional outages.
How often should I check my service?
Match the frequency to the cost of the outage. Revenue-critical endpoints justify 30-second checks; internal tooling is usually fine at 5 or 10 minutes. Higher frequency shortens the time between a failure starting and you hearing about it, but consumes more of your check quota. openstatus supports 30s, 1m, 5m and 10m intervals depending on your plan.
What is the difference between uptime and availability?
Uptime is what your monitor measures: the proportion of checks that succeeded. Availability is what your users experienced, which includes degraded performance your checks may have passed. A service returning HTTP 200 in eight seconds is up but arguably not available. This is why thresholds matter alongside assertions — they let you count slow responses as degraded rather than healthy.
Can I monitor internal services?
Yes. Deploy a private location probe inside your network as an 8.5MB Docker container and it appears as another monitoring region in your dashboard. The probe reaches out to openstatus, so no inbound firewall rule is needed. You can run as many private locations as you like across different VPCs or networks.
How do I monitor a REST or GraphQL API?
Create an HTTP monitor pointing at the endpoint, choose the method, and add any headers your API needs for authentication. For GraphQL, send a POST with the query in the body. Then add assertions on the status code, response headers, or body content so the monitor verifies the response is correct rather than merely present, and set a threshold so slow responses register as degraded.
How much does uptime monitoring cost?
The free Hobby plan includes one monitor at a 10-minute interval with no credit card. Paid plans start at $30/month for Starter (20 monitors, 1-minute checks, 6 regions per monitor), $100/month for Pro (50 monitors, 30-second checks, all 28 regions), and $500/month for Scale. Annual billing gives you two months free.
How many regions should I monitor from?
Start with 3-5 regions covering your main user geographies. More regions provide better global coverage but use more check quota. For critical services, monitor from all major regions (North America, Europe, Asia) to catch regional issues quickly.
Why monitor from multiple cloud providers instead of just one?
If your service runs on AWS and your monitoring also runs on AWS, you won't detect AWS-wide outages or network issues affecting AWS connectivity. Using Fly.io, Koyeb, and Railway ensures monitoring independence from your infrastructure provider.
What's the difference between frequency settings?
Frequency determines how often we check your service (e.g., every 30 seconds, 1 minute, 5 minutes, 10 minutes). Higher frequency (30s) catches issues faster but uses more checks. Lower frequency (10m) is sufficient for non-critical services and conserves quota.
Can uptime monitoring trigger my status page automatically?
Yes, you can configure monitors to automatically update your status page based on monitoring results. When assertions fail or thresholds are exceeded, the status page can reflect degraded or down status without manual intervention.
How do thresholds and assertions work together?
Assertions validate response correctness (status code, headers, body content) while thresholds define performance boundaries (degraded latency, timeout). Both can trigger alerts - assertions catch functional failures, thresholds catch performance degradation.
What types of API endpoints can I monitor?
You can monitor any HTTP/HTTPS endpoint including REST APIs, GraphQL APIs, webhooks, and third-party service endpoints. openstatus supports all HTTP methods (GET, POST, PUT, DELETE, etc.) and custom headers for authentication.
Can I manage monitors with Terraform?
Yes. The openstatus Terraform provider manages HTTP, TCP, DNS and ICMP monitors — with headers, assertions and thresholds — plus notification channels, status pages and private locations. Monitors live in HCL next to the rest of your infrastructure and go through the same plan-and-apply lifecycle. Run `openstatus terraform generate` to bootstrap an HCL file from an existing workspace.
Can I run private monitoring locations in different networks?
Yes, you can deploy as many private location probes as needed across different networks, VPCs, or regions. Each gets its own API key and appears as a separate monitoring region in your dashboard. The Docker image is only 8.5MB and supports ARM64 and AMD64.
---
---
title: "API"
date: Apr 29, 2026
author: "Maximilian Kaske"
description: "A typed JSON-over-HTTP API powered by ConnectRPC — every endpoint the dashboard uses, with a fully typed Node SDK on top."
category: "Product"
---
The openstatus API is a typed, JSON-over-HTTP layer powered by [ConnectRPC](/blog/migrating-from-zod-openapi-to-connectrpc). Every action the dashboard performs is reachable from the API — same workspace, same audit log, same single API key.
## Quickstart
```bash
curl https://api.openstatus.dev/rpc/openstatus.v1.MonitorService/ListMonitors \
-H "x-openstatus-key: os_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{}'
```
Generate a key from **Settings > General > API Keys**.
## What you can do
- Manage monitors, status pages, status reports, maintenance windows, and notification channels.
- Build dashboards or in-app integrations on top of typed JSON responses.
- Use a single key across the API, CLI, Terraform, and MCP server.
- Inspect the full schema in the [OpenAPI explorer](https://api.openstatus.dev/openapi).
## Node SDK
The [openstatus Node SDK](https://github.com/openstatusHQ/sdk-node) is a fully typed TypeScript and JavaScript client for the API — no hand-written `fetch` calls, no codegen step. Works in Node and Deno.
```bash
npm i @openstatus/sdk-node
```
```ts
const client = new Openstatus({ apiKey: process.env.OPENSTATUS_API_KEY });
const monitors = await client.monitors.list();
await client.statusReports.create({ /* ... */ });
```
[Reach out](mailto:ping@openstatus.dev) if you want us to port it to another language.
## Auth & audit
Pass `x-openstatus-key` on every request. The token is the same one the CLI, Terraform provider, and MCP server share.
Every mutation lands in the audit log under `actor_type = 'apiKey'` with the key that made it, so you can trace any change back to a key and the user who created it.
## Other surfaces
- Want a terminal interface or YAML config? See the [CLI](/tooling/cli).
- Managing infrastructure in HCL? Use the [Terraform provider](/tooling/terraform).
- Want Claude or ChatGPT to call your workspace? See the [MCP server](/tooling/mcp-server).
## Reference
Full schema and methods in the [API reference](https://api.openstatus.dev/openapi). SDK docs at [jsr.io/@openstatus/sdk-node](https://jsr.io/@openstatus/sdk-node).
## Frequently asked questions
Should I use the SDK or call the API directly?
Use the Node SDK if you're writing TypeScript or JavaScript — it handles auth, retries, and types for every endpoint. Call the API directly via curl or your language's HTTP client if you're outside the JS ecosystem; ConnectRPC means responses are plain JSON over HTTP.
Is the API REST or RPC?
It's ConnectRPC — JSON over HTTP, but with a typed RPC contract instead of REST conventions. Every method is a POST to `/rpc/openstatus.v1./`. You can call it from curl exactly like you'd call a REST endpoint.
How do I authenticate?
Pass the x-openstatus-key header on every request. Generate a key from Settings > General > API Keys — the same key works for the CLI, Terraform provider, and MCP server.
Do you publish an OpenAPI spec?
Yes. The full schema is browsable at api.openstatus.dev/openapi and is the source of truth for the Node SDK and any generated clients.
---
---
title: "CLI"
date: Apr 29, 2026
author: "Maximilian Kaske"
description: "Manage monitors, status pages, and incidents from your terminal — interactive for humans, scriptable for agents, and YAML-managed for monitoring as code."
category: "Product"
---
The openstatus CLI is the terminal interface to your workspace. It works for both humans (interactive wizards, colors, spinners) and agents (`--json`, deterministic flags, structured errors) — and it lets you keep your monitor configuration as YAML in your repo.
## Quickstart
```bash
brew install openstatusHQ/cli/openstatus --cask
openstatus login
openstatus whoami
openstatus monitors apply
```
Set `OPENSTATUS_API_TOKEN` to skip the login flow in CI.
## What you can do
- Manage monitors, status pages, status reports, and maintenance windows.
- Sync a YAML config with `openstatus monitors apply` — monitoring as code, no HCL required.
- Bootstrap a Terraform configuration from your workspace with `openstatus terraform generate`.
- Pipe `--json` output into `jq`, agents, or your own scripts.
## GitHub Action
Run the CLI from a workflow with the published [GitHub Action](https://github.com/openstatusHQ/cli-action) — drop it into your release pipeline to apply monitor config changes, trigger synthetic checks on deploy, or fail a deploy when a probe regresses.
```yaml
- uses: openstatusHQ/cli-action@v1
with:
api-token: ${{ secrets.OPENSTATUS_API_TOKEN }}
args: monitors apply
```
## AI skills
[Openstatus skills](https://github.com/openstatusHQ/skills) are agent-ready bundles that wrap the CLI for terminal-shaped AI workflows like Claude Code. Install once, then let your agent draft incidents, schedule maintenance, and post status updates on your behalf.
```bash
npx skills add openstatushq/skills
```
You get incident communication templates, maintenance announcement drafts, periodic status reports, and shared status-page context so every skill speaks in your voice.
## Auth & audit
Authenticate with `openstatus login` (browser flow) or `OPENSTATUS_API_TOKEN` (CI). The token is the same one the API, Terraform provider, and MCP server share — generate it from **Settings > General > API Keys**.
Every mutation lands in the audit log under `actor_type = 'apiKey'` with the key that made it, so you can trace any change back to a key and the user who created it. Give the CLI its own key to keep its changes separable from other API callers.
## Other surfaces
- Want chat-shaped AI access from Claude or ChatGPT? See the [MCP server](/tooling/mcp-server).
- Already managing infrastructure in HCL? Use the [Terraform provider](/tooling/terraform).
- Building an in-app integration? Call the [API](/tooling/api) directly.
## Reference
Full command list and flags in the [CLI reference](/docs/reference/cli-reference).
## Frequently asked questions
Is the CLI suitable for AI agents?
Yes. Every command supports --json output and structured errors, and required flags fail with a clear list of what's missing instead of hanging in a wizard. Combined with our agent skills, the CLI is the recommended way to give AI agents scriptable control over openstatus.
Can I run the CLI in CI?
Yes. Set `OPENSTATUS_API_TOKEN`, use the `--json` flag for parseable output, and run `openstatus monitors apply` to sync your YAML config. We also publish a GitHub Action that wraps the CLI for synthetic tests.
What's the difference between the CLI's YAML config and the Terraform provider?
Both treat monitoring as code. The YAML config is lighter to adopt and lives next to your repo. Terraform is the right choice when monitors are part of a larger HCL-managed infrastructure. Run `openstatus terraform generate` to bootstrap an HCL file from your existing workspace if you want to migrate.
Are skills different from the MCP server?
Skills are prompt and command bundles installed into your local agent (Claude Code, etc.) that wrap the openstatus CLI. The MCP server is a remote endpoint that any MCP-compatible client can connect to. Skills are great for terminal-shaped workflows; MCP is great for chat-shaped workflows.
---
---
title: "MCP Server"
date: Apr 29, 2026
author: "Maximilian Kaske"
description: "Connect Claude, ChatGPT, Cursor, and any other Model Context Protocol client to your workspace — sign in with OAuth, pick a workspace, and get audit-logged mutations with explicit notify semantics."
category: "Product"
---
The openstatus MCP server connects Claude Desktop, ChatGPT, Cursor, and any other [Model Context Protocol](https://modelcontextprotocol.io) client to your workspace — so an AI assistant can read monitors, response logs, and audit history, and drive status pages, status reports, and maintenance windows directly from a conversation.
## Quickstart
```
https://api.openstatus.dev/mcp
```
Add the URL as a custom connector in Claude, ChatGPT, or Cursor, or run `claude mcp add --transport http openstatus https://api.openstatus.dev/mcp` for Claude Code. The client opens a consent screen, you pick a workspace and an access level, and the openstatus tools appear in the picker. The server is stateless Streamable HTTP and scales horizontally.
## What you can do
The server exposes **23 tools**, grouped by entity:
- **Status pages** — `list_status_pages` · `list_page_components`
- **Status reports** — `list_status_reports` · `create_status_report` · `add_status_report_update` · `update_status_report` · `resolve_status_report`
- **Maintenance** — `list_maintenances` · `create_maintenance`
- **Incidents** *(10 more, on workspaces with [incident management](/incident-management) enabled)* — `list_incidents` · `get_incident` · `declare_incident` · `update_incident` · `set_incident_status` · `resolve_incident` · `add_incident_note` · `get_postmortem` · `draft_postmortem` · `approve_postmortem`
- **Monitors** — `list_monitors` · `get_monitor` · `get_monitor_status` · `get_monitor_summary`
- **Response logs** — `list_response_logs` · `get_response_log`
- **Notifications** — `list_notifications`
- **Private locations** — `list_private_locations`
- **Audit log** *(workspaces on the audit-log plan only)* — `list_audit_logs` · `get_audit_log`
- **Content** *(public openstatus.dev pages)* — `search_docs` · `get_doc_page` · `search_content` · `get_content_page`
The four **publishing** tools (`create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance`) require `notify: true | false` — the assistant must explicitly choose whether to notify subscribers, so an LLM cannot quietly fan out an alert. `update_status_report` is metadata-only and cannot notify.
The same tool registry powers the [in-app assistant](/blog/from-clickops-to-chatops) — every tool you see in `/chat` is the same tool you call over MCP, kept in sync by shape-equivalence tests.
## Auth & scopes
The MCP server is an OAuth 2.1 authorization server. Connect from any client that implements the MCP authorization spec and you get a consent screen instead of a key to paste: pick the **workspace** and choose **Read-only** or **Read & write**. Tokens rotate automatically, and every connection is listed under **Settings > Integrations > Connected apps**, where it can be revoked with immediate effect.
For CI and headless agents, the `x-openstatus-key` header still works — the same API key the CLI, API, and Terraform use, from **Settings > General > API Keys**.
Both credentials carry a `read` or `write` scope. Read-only connections never see write tools in `tools/list` — they don't exist for that session. Write tools throw a clean error if a read-only credential somehow attempts them.
Every mutation lands in the audit log under `actor_type = 'mcp'`, so you can trace any change back to a connection, a user, and a transport.
## Other surfaces
- Want chat inside the dashboard instead of an external client? See the [in-app assistant](/blog/from-clickops-to-chatops).
- Want a terminal interface for AI agents (Claude Code, etc.)? See [skills](/tooling/cli#ai-skills) on the CLI page.
- Building an in-app integration? Call the [API](/tooling/api) directly.
- Want Slack instead of Claude or ChatGPT? See the [Slack agent](/docs/guides/how-to-setup-slack-agent).
## Setup guides
- [Claude Code](/guides/connect-openstatus-to-claude-code) · [Claude Desktop](/guides/connect-openstatus-to-claude-desktop)
- [Codex](/guides/connect-openstatus-to-codex) · [ChatGPT](/guides/connect-openstatus-to-chatgpt)
- [opencode](/guides/connect-openstatus-to-opencode)
## Reference
Full tool schema, error codes, and per-client config in the [MCP reference](/docs/reference/mcp-server).
## Frequently asked questions
What does the MCP server let an assistant do?
The MCP server exposes 19 read and write tools scoped to your workspace: list status pages, monitors, response logs, notifications, private locations, and audit logs; inspect a single monitor or response log; create, update, and resolve status reports; schedule maintenance windows. Workspaces with incident management enabled get 10 more to declare incidents, change their status, add timeline notes, and draft and approve the postmortem. Every mutation writes to the audit log, and publishing tools require an explicit notify decision.
Are skills different from the MCP server?
Skills are prompt and command bundles installed into your local agent (Claude Code, etc.) that wrap the openstatus CLI. The MCP server is a remote endpoint that any MCP-compatible client can connect to. Skills are great for terminal-shaped workflows; MCP is great for chat-shaped workflows.
Do I need an API key to connect an MCP client?
No. The MCP server is an OAuth 2.1 authorization server: Claude, ChatGPT, Cursor, and other clients open a consent screen where you pick a workspace and read-only or read & write access, and tokens are issued and refreshed automatically. The `x-openstatus-key` header still works for CI and headless agents, with the same key the CLI, API, and Terraform use.
Can the assistant accidentally notify subscribers?
No. Every publishing tool requires the assistant to set notify: true | false explicitly — there's no default. Metadata-only edits like update_status_report can't notify at all. Every mutation lands in the audit log under actor_type = 'mcp', so you can see exactly what happened.
---
---
title: "Terraform"
date: Apr 29, 2026
author: "Maximilian Kaske"
description: "Manage monitors, notifications, and status pages as HCL — same plan-and-apply lifecycle as the rest of your infrastructure, with one command to bootstrap from an existing workspace."
category: "Product"
---
The [openstatus Terraform provider](https://registry.terraform.io/providers/openstatusHQ/openstatus/latest) treats monitoring as code: monitors, notifications, and status pages live in the same plan-and-apply lifecycle as the rest of your infrastructure.
## Quickstart
```hcl
terraform {
required_providers {
openstatus = {
source = "openstatusHQ/openstatus"
}
}
}
resource "openstatus_http_monitor" "api" {
name = "API"
url = "https://api.example.com/health"
periodicity = "1m"
regions = ["fly-iad", "fly-ams", "fly-syd"]
}
```
```bash
export OPENSTATUS_API_TOKEN=os_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
terraform init
terraform plan
terraform apply
```
## What you can do
- Manage every primary entity — monitors, notification channels, status pages, subscribers, maintenance windows — through HCL.
- Roll changes out alongside the rest of your infrastructure (Vercel projects, DNS records, secrets).
- Bootstrap an HCL file from your existing workspace with `openstatus terraform generate` — no hand-writing required.
- Code-review monitor changes in the same PR that adds the service being monitored.
## Bootstrap from an existing workspace
If you already have monitors and status pages in the dashboard, the CLI generates HCL for you:
```bash
openstatus terraform generate
```
The output is a valid HCL configuration with cross-references between resources and `import` blocks pre-wired so `terraform plan` shows zero drift on first run.
## Auth & audit
Set `OPENSTATUS_API_TOKEN` before running Terraform. The token is the same one the CLI, API, and MCP server share — generate it from **Settings > General > API Keys**.
Every mutation through the provider lands in the audit log under `actor_type = 'apiKey'` with the key that made it, so you can trace any change back to a key and the user who created it. Give Terraform its own key to keep its changes separable from other API callers.
## Other surfaces
- Prefer a YAML config in your repo? See the [CLI](/tooling/cli) and `openstatus monitors apply`.
- Building an in-app integration? Call the [API](/tooling/api) directly.
- Want Claude or ChatGPT to read or update status reports? See the [MCP server](/tooling/mcp-server).
## Reference
Full resource list and schema in the [Terraform reference](/docs/reference/terraform).
## Frequently asked questions
How does the Terraform provider compare to the CLI?
The Terraform provider is the right choice if monitoring is part of a larger HCL-managed infrastructure. The CLI's YAML config is lighter to adopt and ships with openstatus terraform generate to bootstrap an HCL file from your existing workspace if you want to migrate.
What resources does the provider expose?
Monitors, notification channels, status pages, status page subscribers, and maintenance windows — every primary entity in the dashboard. See the Terraform reference for the full list and schema.
How do I migrate an existing workspace into Terraform?
Run openstatus terraform generate from the CLI. It fetches your full configuration and produces valid HCL with cross-references and import blocks — no hand-writing required.
Where do I get an API token?
Generate one from Settings > General > API Keys, then set `OPENSTATUS_API_TOKEN` before running terraform plan. The same token works across the CLI, API, and MCP server.
---
---
title: "About openstatus"
date: Nov 10, 2025
author: "openstatus"
description: "Openstatus is built by Thibault and Max — a bootstrapped, profitable two-person team building the open-source status page for teams who ship transparency."
category: "company"
---
[BlueSky](https://bsky.app/profile/thibaultleouay.dev) | [LinkedIn](https://www.linkedin.com/in/thibault-le-ouay-ducasse/) | [GitHub](https://github.com/thibaultleouay/)
[X](https://x.com/mxkaske) | [LinkedIn](https://www.linkedin.com/in/mxkaske/) | [GitHub](https://github.com/mxkaske/)
## Our story
We met on Twitter in 2023 and started building openstatus together. What began as an **open-source** side project driven by curiosity grew into a real business with real impact.
Along the way, we've learned that **boring, reliable tech** beats chasing trends every time. We're committed to building openstatus for the long term.
## Built to last, not to flip
We're **profitable and self-funded**. No VC pressure, no growth-at-all-costs. This matters for you because:
- **We build for customers, not investors.** Every feature ships because it solves a real problem, not because it looks good on a pitch deck.
- **We're not going anywhere.** When your SOC 2 audit comes around next year, we'll still be here. And the year after that.
- **We stay lean and fast.** Two people, no bureaucracy. You can talk to the people who write the code.
## Our mission
We're building the best open-source status page — connecting monitoring, incident communication, and compliance into a single platform. **Transparent by default**, for teams who believe their users deserve to know what's happening.
## Frequently asked questions
What is openstatus?
Openstatus is an open-source status page and uptime monitoring platform founded in 2023 by Thibault Le Ouay Ducasse and Maximilian Kaske. It monitors websites, APIs, and services from 28 regions globally across multiple cloud providers. Openstatus is bootstrapped, profitable, and available both as a managed SaaS and for self-hosting.
Why is openstatus bootstrapped?
We're self-funded because it keeps us aligned with our customers, not investors. No VC pressure means we build features that matter to you, not features that look good on a pitch deck. We'll be here when your next SOC 2 audit comes around.
---
---
title: "Contact"
date: Aug 22, 2026
author: "openstatus"
description: "How to reach openstatus — support email, Discord, GitHub, a call with the founders, security disclosures, and our postal address."
category: "company"
---
Openstatus is built by a two-person team, so whoever answers you also wrote the
code. There is no ticket queue and no support tier — pick whichever channel
fits the question.
## Support
- **Email** — [ping@openstatus.dev](mailto:ping@openstatus.dev). Best for
account, billing, and plan questions. We answer within one business day.
- **Discord** — [join the community](https://www.openstatus.dev/discord) for
setup questions, monitor configuration, and quick answers from other users.
- **GitHub** — [openstatushq/openstatus](https://github.com/openstatushq/openstatus/issues)
for bug reports and feature requests. Openstatus is open source, so the issue
you file is the issue we work from.
- **Call** — [book 30 minutes](https://cal.com/team/openstatus/30min) with the
founders for onboarding, migrations from another status page, or an
architecture review before you roll out monitoring.
## Sales and enterprise
For volume pricing, invoicing, procurement paperwork, security questionnaires,
or a self-hosted deployment, email
[ping@openstatus.dev](mailto:ping@openstatus.dev) with the company name and what
you need. Vendor forms, SOC 2 evidence requests, and DPAs go to the same
address. See [pricing](/pricing) for the published plans and
[subprocessors](/subprocessors) for the vendors we rely on.
## Security
Report vulnerabilities to
[ping@openstatus.dev](mailto:ping@openstatus.dev) rather than in a public
issue — that is the contact published in
[/.well-known/security.txt](/.well-known/security.txt) (RFC 9116). The
disclosure policy lives on
[GitHub](https://github.com/openstatusHQ/openstatus/security/policy) and the
rest of our posture is on the [security page](/security).
## Press and partnerships
Email [ping@openstatus.dev](mailto:ping@openstatus.dev) for logos, screenshots,
quotes, or open-source partnership requests. Our story is on the
[about page](/about).
## Postal address
OpenStatus SAS
122 Rue Amelot
75011 Paris
France
## For agents
Machine-readable contact details are published as `Organization` JSON-LD on
every page of this site, in
[/.well-known/security.txt](/.well-known/security.txt), and in the
[API catalog](/.well-known/api-catalog). The support email
`ping@openstatus.dev` is the correct destination for anything that needs a
human.
---
---
title: "Health Endpoints"
date: Sep 17, 2026
author: "openstatus"
description: "Build a health endpoint that says what is broken. @openstatus/health runs one probe per dependency and answers ok, degraded, or unhealthy — on Node, Bun, Deno, and edge runtimes."
category: "Documentation"
---
A monitor that polls your homepage for a `200` tells you the process is alive. It does not tell you that your database is gone, that your cache is timing out, or that the queue you depend on stopped accepting writes — all of which happily return `200` right up until the moment they matter.
[`@openstatus/health`](https://github.com/openstatusHQ/health) is the toolkit we extracted from our own services to close that gap. You describe one probe per dependency; it runs them concurrently, caches the result, and renders a JSON report that says `ok`, `degraded`, or `unhealthy` — and which dependency is responsible.
Zero dependencies. Runs on Node 22+, Bun, Deno, and edge runtimes. MIT licensed.
## Install
```bash
npm install @openstatus/health
```
Or from JSR:
```bash
deno add jsr:@openstatus/health
```
## Quickstart
```ts
const handler = createHealthHandler({
path: "/health",
probes: [
{
name: "database",
critical: true,
run: () => db.run(sql`select 1`),
},
{
name: "redis",
skip: () => readEnv("UPSTASH_REDIS_REST_URL") == null,
run: () => redis.ping(),
},
httpProbe({ name: "unkey", url: "https://api.unkey.com/v2/liveness" }),
],
});
Deno.serve(handler);
```
`createHealthHandler` returns a plain `(request: Request) => Promise`, so anything that speaks the Fetch API needs no adapter — Next.js route handlers, SvelteKit, Astro, Nitro, Fresh, React Router resource routes, `Bun.serve`, `Deno.serve`:
```ts
export const GET = createHealthHandler({ probes });
```
For frameworks with their own request objects, there is a thin adapter:
```ts
app.route("/", healthRoute({ path: "/ping", probes }));
```
## The response
```json
{
"status": "degraded",
"checkedAt": "2026-09-11T12:00:00.000Z",
"latencyMs": 41,
"checks": [
{ "name": "database", "status": "ok", "critical": true, "latencyMs": 3 },
{ "name": "redis", "status": "skipped", "critical": false, "latencyMs": 0 },
{ "name": "unkey", "status": "timeout", "critical": false, "latencyMs": 5000, "error": "timed out after 5000ms" }
]
}
```
One failing dependency does not have to mean the whole service is down. Marking a probe `critical` is how you say the difference:
| Probe results | Report status | Default HTTP status |
| --- | --- | --- |
| every probe `ok` or `skipped` | `ok` | `200` |
| a non-critical probe failed or timed out | `degraded` | `200` |
| a critical probe failed or timed out | `unhealthy` | `503` |
`HEAD` returns the same status code with no body. Other methods get `405` with an `allow: GET, HEAD` header. Every response carries `content-type: application/json` and `cache-control: no-store`.
## Probes
A probe is an object with a `name` and a `run` function. It is healthy when `run` resolves and failed when it throws:
```ts
interface Probe {
name: string;
critical?: boolean; // default false
timeoutMs?: number; // default 5000
skip?: () => boolean | Promise;
run: (signal: AbortSignal, ctx: ProbeContext) => unknown | Promise;
}
```
The `signal` aborts when `timeoutMs` elapses — pass it to `fetch` and other cancellable calls. A probe that ignores it and settles late is still reported as `timeout`; the late result is discarded and can never surface as an unhandled rejection.
`skip` runs first, inside the same timeout window, and reports the check as `skipped` without calling `run`. It is how you handle a dependency that is not configured in every environment, and it may be async, so feature flags and secret lookups work too.
You can write every probe by hand, or pull in a ready-made one. Each factory takes a client or a URL — never the environment — and validates its options at construction, so a missing URL throws a `ProbeConfigError` naming the probe and the field instead of a bare `Invalid URL` from somewhere inside the library.
## The package family
The core is one package in a family. Adapters mount it on your framework, probes know how to ping one dependency each, and hosting packages say which replica answered.
| | Packages |
| --- | --- |
| **Adapters** | `health-hono`, `health-elysia`, `health-express`, `health-next`, `health-tanstack-start` |
| **Probes** | `health-drizzle`, `health-supabase`, `health-tinybird`, `health-turso`, `health-turso-serverless`, `health-unkey`, `health-upstash` |
| **Hosting** | `health-fly`, `health-koyeb`, `health-railway`, `health-vercel`, `health-cloudflare` |
Every one of them is published under the `@openstatus` scope on both npm and [JSR](https://jsr.io/@openstatus). The full table, with a quick start for each adapter, is in the [repository README](https://github.com/openstatusHQ/health#packages).
## Options worth knowing
| Option | Default | What it does |
| --- | --- | --- |
| `cacheMs` | `5000` | Reuse the last `ok` report for this long; concurrent callers share one round. |
| `cacheFailuresMs` | `cacheMs` | Same, for `degraded` and `unhealthy`. Set `0` so a poller sees recovery on its next tick instead of waiting out the cache. |
| `staleMs` | `0` | Stale-while-revalidate: keep answering with the last report while one refresh runs in the background. |
| `timeoutMs` | `5000` | Default per-probe timeout. A hung probe reports `timeout`. |
| `deadlineMs` | — | Upper bound for the whole round, capping every probe's timeout. Set it below your prober's own timeout. |
| `exposeChecks` | `true` | `false` returns only `status` and `checkedAt`. A function decides per request. |
| `extend` | — | `(report, ctx) => object` merged into the body — a request id, a region, a `server` object from a hosting package. |
| `formatError` | `"generic"` | Probe errors are masked by default. `"message"` surfaces the real one while developing. |
| `onReport` | — | Called once per uncached round. Log it, emit a metric, page on `unhealthy`. |
> **Caution**
>
> `deadlineMs` is the one to set deliberately. Kubernetes readiness probes default to a one-second timeout, and Fly's HTTP checks to five — if the whole round can outlast the prober's patience, the prober records a timeout and never reads the report you worked to produce.
## How we use it
Our API runs on Fly, behind an HTTP check with a five-second timeout. The `/ping` route is four probes and an `extend` that names the machine that answered:
```ts
export const pingRoute = healthRoute({
path: "/ping",
deadlineMs: 4_000,
probes: [
tursoProbe({ client: db.$client }),
tinybirdProbe({
baseUrl: env.TINYBIRD_URL,
skip: () => isTinybirdNoop(env.TINYBIRD_NOOP),
}),
unkeyProbe(),
upstashProbe({
url: env.UPSTASH_REDIS_REST_URL,
token: env.UPSTASH_REDIS_REST_TOKEN,
}),
],
extend: (_report, c) => ({
server: flyServer(),
requestId: c.get("requestId"),
}),
});
```
The same shape backs the dashboard and the status pages, where `vercelExtend` reports the deployment instead.
## Monitor it with openstatus
A health endpoint is only worth writing if something reads it. Point an [HTTP monitor](/docs/reference/http-monitor) at the URL and add a body assertion:
> **Body** · **Contains** · `"status":"ok"`
That assertion is the point. `degraded` answers `200` by default — deliberately, so a non-critical outage does not take you out of a load balancer — which means a status-code assertion alone will never tell you about it. Asserting on the body catches `degraded` while it is still only degraded, and you hear about the failing cache before it becomes the failing checkout.
[Monitor your health endpoint](https://app.openstatus.dev?ref=health)
## Learn more
- [github.com/openstatusHQ/health](https://github.com/openstatusHQ/health) — source, full package table, and issues
- [jsr.io/@openstatus](https://jsr.io/@openstatus) — API reference for every package
- [HTTP monitor reference](/docs/reference/http-monitor) — assertions, regions, and timeouts
- [Component Registry](/registry) — our other open-source building blocks
## Support
If you hit a problem, have a question, or want a probe or adapter we do not ship yet:
- [Open an issue](https://github.com/openstatusHQ/health/issues)
- [Join our Discord](https://openstatus.dev/discord)
- [Send an email](mailto:ping@openstatus.dev)
---
---
title: "Pricing"
date: Nov 10, 2025
author: "Maximilian Kaske"
description: "Start free with uptime monitoring and a status page. Upgrade to Starter ($30/mo), Pro ($100/mo), or Scale ($500/mo) for more monitors, team collaboration, and advanced features. No credit card required."
category: "company"
---
New workspaces start with a 14-day Starter trial, no card needed.
| Features comparison | $30/month - Starter | $100/month - Pro | $500/month - Scale |
| --- | --- | --- | --- |
| [Status Pages](/status-page) | | | |
| Number of status pages | 1 +$20/mo./each | 5 +$20/mo./each | 10 +$20/mo./each |
| Number of components | 20 | 50 | 500 |
| Maintenance status | + | + | + |
| Toggle numbers visibility | + | + | + |
| Subscribers | + | + | + |
| Custom domain | + | + | + |
| Custom theme | $20/mo. | + | + |
| Locale switcher | + | + | + |
| Slack Agent | + | + | + |
| White Label | $300/mo. | $300/mo. | + |
| **Audience** | | | |
| Password Protection | + | + | + |
| Email Authentification | $100/mo. | $100/mo. | + |
| IP Restriction | $100/mo. | $100/mo. | + |
| [Monitors](/uptime-monitoring) | | | |
| Check Interval | 1m | 30s | 30s |
| Number of monitors | 20 +$15/mo./10 | 50 +$15/mo./10 | 50 +$15/mo./10 |
| Multi-region monitoring | + | + | + |
| Total regions | 28 | 28 | 28 |
| Regions per monitor | 6 | 28 | 28 |
| Data retention | 3 months | 12 months | 24 months |
| Response logs | + | + | + |
| Private locations | | + | + |
| OTel Exporter | | + | + |
| **Alerts** | | | |
| Slack, Discord, Email, Webhook | + | + | + |
| WhatsApp | + | + | + |
| PagerDuty | + | + | + |
| OpsGenie | + | + | + |
| Grafana OnCall | + | + | + |
| Number of notification channels | 10 | 20 | 20 |
| **Collaboration** | | | |
| Team members | Unlimited | Unlimited | Unlimited |
| Audit log | | + | + |
| SSO/SAML | $250/mo. | $250/mo. | $250/mo. |
## Enterprise
For teams that need more than what Scale offers — **SOC2 reports**, **SAML/SSO**, **custom regions**, **higher monitor and status page limits**, a **dedicated SLA**, custom contracts, and invoicing. We will tailor a plan to your requirements.
[Contact us](mailto:ping@openstatus.dev)
## Frequently asked questions
Do you offer a free plan?
Yes. Our free **Hobby** plan includes **one monitor**, **one status page with three components**, and a minimum check interval of **10 minutes**. No credit card required.
Is there a free trial?
Yes. New workspaces start with a **14-day trial of the Starter plan**, no credit card required. If you have not added a card by then, the workspace returns to the free Hobby plan.
Do you offer refunds?
Yes. If you are not happy with openstatus, reach out at [ping@openstatus.dev](mailto:ping@openstatus.dev) within **30 days** of your payment and we will issue a full refund — no questions asked.
What billing options are available?
All paid plans are available with **monthly** or **annual** billing. Choose annual billing to get **2 months free** — Starter at **$300/year** ($25/mo), Pro at **$1,000/year** ($83/mo), and Scale at **$5,000/year** ($416/mo).
Can I switch between monthly and annual billing?
Yes. You can switch between monthly and annual billing at any time from your dashboard.
What are add-ons and how are they billed?
Add-ons are workspace-level settings like **White Label**, **Custom Theme**, **Email Authentication**, **IP Restriction**, **extra status pages**, and **extra monitors**. Once enabled, they apply to your entire workspace. Add-ons are billed monthly regardless of your plan's billing cycle.
Can I upgrade or downgrade my plan?
Yes. You can upgrade or downgrade at any time from your dashboard. Changes take effect immediately, and billing is prorated.
What currencies do you support?
We support **EUR** and **USD**. Contact us at [ping@openstatus.dev](mailto:ping@openstatus.dev) or [book a call](https://openstatus.dev/cal) if you have questions about pricing in your currency.
Can I cancel my subscription at any time?
Yes. You can cancel anytime from your dashboard. Your plan stays active until the end of the current billing period, and you will not be charged again.
What happens if I exceed my plan limits?
We will never stop your monitors or status pages without notice. If you approach or exceed a limit, we will reach out to help you pick the right plan. Add-ons like extra status pages and monitor packs are billed per unit as listed in the comparison table.
Do you offer custom or enterprise plans?
Yes. If you need higher limits, custom regions, SSO, a dedicated SLA, or a custom contract, [book a call](https://openstatus.dev/cal) and we will tailor a plan to your needs.
What payment methods do you accept?
We accept all major credit and debit cards through **Stripe**. For annual plans we can also issue invoices on request — contact us at [ping@openstatus.dev](mailto:ping@openstatus.dev).
---
Go to the dashboard and get started
[Create Account](https://app.openstatus.dev)
---
---
---
title: "Privacy"
date: Apr 28, 2026
author: "openstatus"
description: "The privacy conduct for openstatus"
category: "company"
---
Welcome to [openstatus.dev](/) (the "Site"), hosted by openstatus ("openstatus",
"we", "us", and/or "our"). openstatus provides an open-source synthetic
monitoring platform that lets users monitor websites and APIs and receive
notifications when they are down or slow (the "Services"). We value your
privacy and are dedicated to protecting your personal data. This Privacy Policy
covers how we collect, handle, store, and disclose personal data on our
Platform.
If you have any questions, comments, or concerns regarding this Privacy Policy,
our data practices, or would like to exercise your rights, do not hesitate to
contact us at privacy@openstatus.dev.
## To Whom Does This Policy Apply
This Privacy Policy applies to customers and site visitors. Each customer is
responsible for posting its own terms, conditions, and privacy policies, and
ensuring compliance with all applicable laws and regulations.
## Changes To This Privacy Policy
This Privacy Policy may change from time to time, as our Platform and our
business may change. Your continued use of the Platform after any changes to
this Privacy Policy indicates your agreement with the terms of the revised
Privacy Policy.
## What Information Do We Collect
We collect the following categories of information:
- **Account information** you provide when signing up or updating your profile:
name, email address, profile photo, and authentication identifiers from the
identity provider you choose (e.g. GitHub or Google OAuth subject IDs).
- **Workspace and billing information**: workspace name, billing address, tax
identifiers, and payment metadata returned by our payment processor (Stripe).
We do not store full card numbers ourselves.
- **Configuration data** you submit to operate the Services: monitor URLs,
request headers, request bodies, assertions, status page configurations,
notification channel destinations (email addresses, Slack/Discord/Microsoft
Teams webhook URLs and bot tokens, OpsGenie/PagerDuty integration keys,
SMS phone numbers), and incident notes.
- **Third-party integration credentials and identifiers** that you choose to
connect — for example, Slack workspace IDs, channel IDs, bot tokens, and
user IDs returned during the OAuth install. We use these solely to deliver
the integration's features (e.g. posting status updates to a Slack channel).
- **Monitoring results and telemetry generated by the Services**: HTTP status
codes, response timings, response headers and bodies (when you opt in),
TCP/DNS check results, and trace data from the regions you select.
- **Usage and device information**: log data such as IP address, browser type,
pages viewed, referring URL, and timestamps. We use privacy-friendly analytics
tools and do not use third-party advertising cookies.
- **Communications** you send us, such as support requests and feedback.
We collect this information directly from you when you provide it on the Site,
automatically when you use the Services, and from integration providers when
you authorize them (e.g. Slack returns workspace and user identifiers during
the OAuth flow).
## What We Use Your Information For
We use your information to:
- Provide, operate, and secure the Services, including running monitoring
checks and delivering notifications you have configured.
- Authenticate you and manage your workspace, billing, and subscriptions.
- Communicate with you about your account, service updates, and support
requests.
- Improve the Platform, debug issues, and prevent abuse.
- Comply with legal obligations.
We do not sell your personal data, and we do not use it for third-party
advertising.
## How We Share Your Information
We share personal data only with the sub-processors required to operate the
Services, including our hosting and database providers, our payment processor
(Stripe), our transactional email provider, our error-monitoring provider, and
the third-party notification platforms you explicitly connect (such as Slack,
Discord, Microsoft Teams, OpsGenie, PagerDuty, or SMS gateways). We may also
disclose information when required by law.
## Data Retention
We retain personal data only for as long as is necessary for the purposes set
out in this Privacy Policy:
- **Account and workspace data** is retained for as long as your account
remains active. If you delete your account or workspace, we delete or
anonymize the associated personal data within 30 days, except where we are
required to retain it for legal, accounting, or fraud-prevention purposes.
- **Billing records** are retained for the period required by applicable tax
and accounting law (typically up to 7 years).
- **Monitoring results and telemetry** are retained according to the data
retention window of your subscription plan, after which they are deleted or
aggregated.
- **Application logs** containing IP addresses and request metadata are
retained for up to 30 days for security and debugging purposes.
- **Third-party integration tokens** (e.g. Slack bot tokens) are retained
until you uninstall the integration or delete the workspace, after which
they are deleted within 30 days.
When you uninstall the Slack app — either from the Slack workspace or from
within openstatus — we revoke the OAuth grant and delete the associated bot
token, workspace ID, and channel mappings within 30 days.
## Your Rights
Depending on your jurisdiction (including under the GDPR, UK GDPR, and CCPA),
you may have the following rights regarding your personal data:
- **Right of access** — request a copy of the personal data we hold about you.
- **Right to rectification** — ask us to correct inaccurate or incomplete
information.
- **Right to erasure ("right to be forgotten")** — request that we delete your
personal data.
- **Right to restrict or object to processing** — ask us to limit how we use
your data.
- **Right to data portability** — receive your data in a structured,
machine-readable format.
- **Right to withdraw consent** — where processing is based on consent, you
may withdraw it at any time.
- **Right to lodge a complaint** with your local data protection authority.
You can exercise most of these rights directly from your account settings —
you can edit or delete your profile, export your workspace data, and delete
your workspace from the dashboard. To make any other request, or if you need
help, email us at privacy@openstatus.dev. We will respond within 30 days. We
may need to verify your identity before fulfilling the request, and we will
not charge a fee unless the request is manifestly unfounded or excessive.
## How To Contact Us
For privacy-related questions or to exercise any of the rights above, please
contact us at privacy@openstatus.dev.
---
For how we protect data across these providers, see our [security page](/security).
---
---
title: "Component Registry"
date: Feb 08, 2026
author: "openstatus"
description: "Install beautiful, accessible React components for status pages. Pre-built, customizable components compatible with shadcn/ui."
category: "Documentation"
---
Build your status page in minutes, not hours. The openstatus registry provides production-ready React components specifically designed for status pages. Built on top of [shadcn/ui](https://ui.shadcn.com), these components are accessible, customizable, and battle-tested in production.
## What is the Registry?
The openstatus registry is a collection of shadcn/ui-compatible, pre-built components for common status page patterns. Instead of building status indicators, event timelines, and monitoring displays from scratch, install and customize these components directly into your project.
All components are:
- **Accessible** - Built with ARIA patterns and keyboard navigation
- **Customizable** - Fully themeable with Tailwind CSS
- **Type-safe** - Written in TypeScript with complete type definitions
- **Localizable** - Optional i18n provider for translated labels and locale-aware date formatters; English defaults out of the box
- **Production-ready** - Battle-tested in production at openstatus
## Example
Hover over the example below to see which component is being used.
> We are working on aligning component `Props` with [`@openstatus/sdk-node`](https://jsr.io/@openstatus/sdk-node) return values, enabling you to use our SDK to build your own custom status page.
View the [GitHub source code](https://github.com/openstatusHQ/openstatus/tree/main/apps/web/src/content/shadcn-registry-example.tsx) for examples and usage patterns.
## Installation
> **Prerequisites:** these components target an initialised **shadcn project on Tailwind CSS v4**. If you're starting from scratch (Astro, Vite, etc.), run `shadcn init` first — it creates `components.json`, the `@/*` path alias, and your Tailwind v4 CSS entry. Tested with the latest shadcn CLI (`shadcn@latest`).
Install any component with a single [shadcn CLI](https://ui.shadcn.com/docs/cli) command:
```bash
npx shadcn@latest add https://openstatus.dev/r/status-complete
```
Or install the registry first:
```bash
pnpm dlx shadcn@latest registry add @openstatus
```
And install the component via:
```bash
pnpm dlx shadcn@latest add @openstatus/status-complete
```
### Available Components
Components are organized by functionality:
- **Collections:** `status-complete` (everything — body + chrome), `status-essentials` (body subset), `status-chrome` (header + footer + switchers + status-updates) - Full status page bundles
- **Body Blocks:** `status-banner`, `status-bar`, `status-calendar`, `status-feed`, `status-events`, `status-component`, `status-component-group`, `status-blank`, `status-icon`, `status-layout`, `status-timestamp` - Individual components for the page body
- **Chrome Blocks:** `status-page-shell`, `status-page-header`, `status-page-footer`, `status-page-get-in-touch`, `status-updates`, `status-theme-switcher`, `status-locale-switcher` - Header, footer, and surrounding chrome for a full status page
- **i18n:** `status-i18n` - Optional context provider + hook for translated labels and locale-aware date formatters (auto-installed as a dependency of the blocks above)
Explore the full registry at [openstatus.dev/r/registry.json](https://openstatus.dev/r/registry.json)
> **Tip:** `status-complete` installs every feature and pulls extra dependencies (`next-themes`, `sonner`, `react-day-picker`, `@date-fns/utc`). If you only need the page body, `status-essentials` is the lighter entry point.
### Localization
Blocks ship with English (`en-US`) defaults and require zero setup. To localize, mount `` near your app root and pass a `StatusBlocksLabels` value (translated strings + locale-aware date formatters built from your own i18n library — `next-intl`, `react-intl`, or whatever you use). Blocks read labels via `useStatusBlocksLabels()`; if no provider is mounted, they fall back to `defaultStatusBlocksLabels`.
This contract keeps the registry library-agnostic — `@openstatus/ui` does not depend on `next-intl` or any other i18n package directly.
---
Want to customize your theme?
## Learn More
- [Source Code Example](https://github.com/openstatusHQ/openstatus/tree/main/apps/web/src/content/shadcn-registry-example.tsx) - See all components in action
- [Blog Post](/blog/shadcn-component-registry) - How We Build Our shadcn Component Registry
- [Openstatus SDK](https://jsr.io/@openstatus/sdk-node) - Build on top of openstatus with our SDK
- [shadcn/ui Documentation](https://ui.shadcn.com) - Learn about the underlying component system
- [Openstatus GitHub](https://github.com/openstatusHQ/openstatus) - Star the project and contribute
- [Theme Explorer](https://themes.openstatus.dev) - Explore community themes
## Support
If you encounter issues, have questions, or want to share feedback:
- [Open an issue](https://github.com/openstatusHQ/openstatus/issues)
- [Join our Discord](https://openstatus.dev/discord)
- [Check the documentation](https://www.openstatus.dev/docs)
- [Send an email](mailto:ping@openstatus.dev)
---
---
title: "Security"
date: May 28, 2026
author: "openstatus"
description: "How openstatus protects your data, where it lives, and how to reach us if you find something."
category: "company"
---
Security at openstatus rests on three things: open-source code, the ability to self-host, and a public list of every system we touch. This page describes how we protect data in the hosted product and how to reach us if you find something.
## Open by default
**Auditable code**
Every line of openstatus is on [GitHub](https://github.com/openstatushq/openstatus). You can read it, fork it, or open a pull request.
**Self-hostable**
Don't want your data on our infrastructure? Run openstatus on your own — the [self-hosting guide](https://www.openstatus.dev/docs/guides/self-hosting-openstatus) walks through it.
**Public sub-processors**
The full list of services we use to run openstatus.dev is public at [/subprocessors](/subprocessors) — no NDA, no trust center login.
## Data protection
All traffic to openstatus.dev and the API is served over HTTPS with modern TLS. Data is encrypted at rest by our infrastructure providers — primary databases on [Turso](https://turso.tech), analytics on [Tinybird](https://tinybird.co), application hosting on [Vercel](https://vercel.com) and [Fly](https://fly.io). The full list, with regions and purpose, is on the [sub-processors page](/subprocessors).
Application secrets — third-party tokens, webhook URLs, integration credentials — are stored as environment variables in our hosting providers, never committed to the repository. Integration credentials you submit (Slack bot tokens, OpsGenie keys, etc.) are stored encrypted in the database and stripped from audit log entries.
## Authentication and access
You sign in with GitHub or Google OAuth, an email magic link, or your company's SSO provider. Account sign-in never involves a password, so there is none for openstatus to see or store.
API access uses scoped keys: a key with the `read` scope can only call read-only endpoints; a key with the `write` scope can mutate data. Scopes are enforced before any database lookup, so a read-only key can't even reach a write code path.
Every workspace is isolated. Every database read and write is filtered by workspace ID at the service layer — there is no shared state between workspaces.
Every mutation in your workspace — whether it comes from the dashboard, the API, MCP, or the Slack integration — is recorded in an append-only audit log. Workspace members on **Pro** can browse it at `/settings/audit-logs` in the dashboard. If a teammate changes a monitor, deletes an integration, or rotates an API key, it's on record.
## Where your data lives
We default to EU-hosted infrastructure wherever the provider offers it: queues on [GCP](https://cloud.google.com) (EU), analytics on Tinybird (EU), email on [Resend](https://resend.com) (EU), product analytics on [Openpanel](https://openpanel.dev) (EU). Application hosting and the primary database run globally on Vercel, Fly, Koyeb, Railway and Turso.
The complete list, with purpose and region for each provider, lives at [/subprocessors](/subprocessors).
## Operational practices
Every change to openstatus goes through a pull request on GitHub. PRs are reviewed by a human and by automated code review before merge. CI runs lint, type-check, and tests on every commit.
We publish a [public changelog](/changelog) for every meaningful change to the product, so you can see what shipped and when.
Larger architectural decisions are written up as ADRs in the repo's [`/docs/adr`](https://github.com/openstatusHQ/openstatus/tree/main/docs/adr) folder, so the reasoning behind each one is on record.
## Reporting a vulnerability
If you find a security issue, email [ping@openstatus.dev](mailto:ping@openstatus.dev). We acknowledge reports within three business days and keep you informed until the issue is resolved. The full disclosure policy is in [SECURITY.md](https://github.com/openstatushq/openstatus/blob/main/SECURITY.md), and our RFC 9116 contact is at [/.well-known/security.txt](/.well-known/security.txt).
For privacy questions, see our [privacy policy](/privacy) or email the same address.
---
---
title: "Subprocessors"
date: Nov 10, 2025
author: "openstatus"
description: "The list of subprocessors for openstatus"
category: "company"
---
## List of Subprocessors
Vercel:
- Purpose: Server hosting
- Location: Global
Fly:
- Purpose: Server hosting
- Location: Global
Koyeb:
- Purpose: Server hosting
- Location: Global
Railway:
- Purpose: Server hosting
- Location: Global
GCP:
- Purpose: Queue
- Location: EU
Turso:
- Purpose: Relational database (SQLite)
- Location: Global
Tinybird:
- Purpose: Analytical database (Clickhouse)
- Location: EU
Stripe:
- Purpose: payment processing
- Location: US
Resend:
- Purpose: Email sending
- Location: EU
Openpanel:
- Purpose: Product analytics
- Location: EU
For how we protect data across these providers, see our [security page](/security).
---
---
title: "Terms of Service"
date: Nov 10, 2025
author: "openstatus"
description: "The terms and conditions for openstatus"
category: "company"
---
Subject to these Terms of Service (this "Agreement"), [openstatus.dev](/)
("OpenStatus", "we", "us" and/or "our") provides access to OpenStatus's cloud
platform as a service (collectively, the "Services"). By using or accessing the
Services, you acknowledge that you have read, understand, and agree to be bound
by this Agreement.
If you are entering into this Agreement on behalf of a company, business or
other legal entity, you represent that you have the authority to bind such
entity to this Agreement, in which case the term "you" shall refer to such
entity. If you do not have such authority, or if you do not agree with this
Agreement, you must not accept this Agreement and may not use the Services.
## 1. Acceptance of Terms
By signing up and using the services provided by OpenStatus (referred to as the
"Service"), you are agreeing to be bound by the following terms and conditions
("Terms of Service"). The Service is owned and operated by OpenStatus ("Us",
"We", or "Our").
## 2. Description of Service
OpenStatus provides an open source monitoring and status page tool. ("the
Product"). The Product is accessible at openstatus.dev and other domains and
subdomains controlled by Us (collectively, "the Website").
## 3. Fair Use
You are responsible for your use of the Service and for any content that you
post or transmit through the Service. You may not use the Service for any
purpose that is illegal or infringes upon the rights of others.
We reserve the right to suspend or terminate your access to the Service if we
determine, in our sole discretion, that you have violated these Terms of
Service, including but not limited to, adding phishing links, spam links, scam
links, or other inappropriate or illegal content.
## 4. Intellectual Property Rights
You acknowledge and agree that the Service and its entire contents, features,
and functionality, including but not limited to all information, software, code,
text, displays, graphics, photographs, video, audio, design, presentation,
selection, and arrangement, are owned by Us, our licensors, or other providers
of such material and are protected by United States and international copyright,
trademark, patent, trade secret, and other intellectual property or proprietary
rights laws.
## 5. Changes to these Terms
We reserve the right to revise and update these Terms of Service from time to
time in our sole discretion. All changes are effective immediately when we post
them, and apply to all access to and use of the Website thereafter. Your
continued use of the Website following the posting of revised Terms of Service
means that you accept and agree to the changes.
## 6. Contact Information
Questions or comments about the Website or these Terms of Service may be
directed to our support team at support@openstatus.dev.
## 7. Disclaimer of Warranties
THE SERVICE AND ITS CONTENT ARE PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS
WITHOUT ANY WARRANTIES OF ANY KIND. WE DISCLAIM ALL WARRANTIES, INCLUDING, BUT
NOT LIMITED TO, THE WARRANTY OF TITLE, MERCHANTABILITY, NON-INFRINGEMENT OF
THIRD PARTIES’ RIGHTS, AND FITNESS FOR PARTICULAR PURPOSE.
## 8. Limitation of Liability
IN NO EVENT WILL WE, OUR AFFILIATES OR THEIR LICENSORS, SERVICE PROVIDERS,
EMPLOYEES, AGENTS, OFFICERS OR DIRECTORS BE LIABLE FOR DAMAGES OF ANY KIND,
UNDER ANY LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH YOUR USE, OR
INABILITY TO USE, THE WEBSITE, THE SERVICE, ANY WEBSITES LINKED TO IT, ANY
CONTENT ON THE WEBSITE OR SUCH OTHER WEBSITES, INCLUDING ANY DIRECT, INDIRECT,
SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES.
## 9. Governing Law and Jurisdiction
These Terms of Service and any dispute or claim arising out of or related to
them, their subject matter or their formation (in each case, including
non-contractual disputes or claims) shall be governed by and construed in
accordance with the internal laws of France without giving effect to any choice
or conflict of law provision or rule. Any legal suit, action, or proceeding
arising out of, or related to, these Terms of Service or the Website shall be
instituted exclusively in the federal courts of France.
---
By using OpenStatus , you acknowledge that you have read these Terms of Service,
understood them, and agree to be bound by them. If you do not agree to these
Terms of Service, you are not authorized to use the Service. We reserve the
right to change these Terms of Service at any time, so please review them
frequently.
Thank you for using OpenStatus!