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 it in Slack, or with your favorite agent
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 declare it from there.
- 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.
Everyone hears it from you first
/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.
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.
Only the right people see it
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.
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 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, newest first: monitor.alert at 09:41:12, 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. 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.