Run status pages and incident response from Slack or your AI agent.
Open source status page, incident response and global uptime monitoring. When something breaks, your subscribers hear it first and your auditor gets the trail.
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.
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
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.
- 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.
Mitigate in the channel, update the page
The rollback lands and one slash command marks the incident mitigated. The linked status report moves to monitoring with its own public wording, and subscribers hear about it without anyone leaving Slack.
/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. Below it, the linked status report "Elevated errors on Checkout API" reads Monitoring, with its own public message and 1,337 subscribers notified.
The postmortem arrives as a draft
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.
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.
The record stays public
Every update stays on the status page with its timestamp. When a prospect asks how you handle outages, the answer is already in your incident history.
The same incident a week later in the status page's events feed: four timestamped updates from investigating at 09:44 to resolved at 10:36.
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.
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 incident response platform. Monitor from 28 regions, publish a branded status page on your own domain, and manage it from Slack, an AI agent, the dashboard, CLI, API or Terraform.
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.