The status page that just works.
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.
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
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.
POST https://api.piedpiper.dev/v1/checkoutExpected status code 200, received 503
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.
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.
/openstatus incident declare Checkout API 503s in EU --sev major- Title
- Checkout API 503s in EU
- Severity
- Major
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
- Title
- Elevated errors on Checkout API
- Status
- Investigating
- Affected
- Checkout API
- Message
- We are investigating elevated error rates on the Checkout API from European regions. Payments outside Europe are not affected.
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.
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.
/openstatus unsubscribeThe 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.
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".
/openstatus incident mitigate Rollback complete in eu-west-1 and eu-west-2.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
A configuration change in the European edge made the Checkout API return 503 for requests routed through Europe.
Checkout requests routed through Europe failed for 55m, from 09:41 to 10:36 UTC. Payments outside Europe were not affected.
- 09:43 UTC Declared
- 09:44 UTC Status report linked
- 09:49 UTC Note
- 10:14 UTC Mitigated
- 10:36 UTC Resolved
The 09:38 edge config deploy changed EU routing and was not validated against a European region before rollout.
The monitor alerted within a minute and the first public update went out three minutes later.
The deploy had no canary, so every European region failed at once.
- [ ] Canary edge config changes in one EU region first
- [ ] Add a pre-deploy check from lhr and koyeb_fra
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.
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.
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.”
“We picked openstatus because the workflow matched ours. We stayed because it keeps matching.”
For humans and agents
Every action in the dashboard is reachable programmatically. One API key, four ways in.
- CLI for the terminal and CI, with
--jsonoutput for scripts. - API with typed endpoints, an OpenAPI spec and a Node SDK.
- MCP server so Claude, ChatGPT or Cursor can run it for you.
- 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 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
No account yet? Check any URL's response time from 28 regions, 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, API, Terraform or an AI agent.
It is used by teams like Cal.com, WhiteBIT, and Documenso, and available as a managed service or for self-hosting.
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 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.
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.
The source code is on GitHub.
Who is behind openstatus?
Openstatus is built by Thibault and Max, 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.