--- title: "Open Source Status Page, Uptime Monitoring & Incident Response" url: "https://www.openstatus.dev/" date: "2026-04-07" updated: "2026-10-16" author: "openstatus" description: "Open source status page, incident response and global uptime monitoring. When something breaks, your subscribers hear it first and your auditor gets the trail." category: "product" --- [Get started free](https://app.openstatus.dev) [GitHub 9k+](https://openstatus.dev/github) Free to start. Try Starter free for 14 days, 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. ## 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 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) 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. - [Incident management](/incident-management) - [Status page](/status-page) 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. - [Incident management](/incident-management#a-postmortem-with-a-first-draft) - [MCP server](/tooling/mcp-server) 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. - [Status page](/status-page) - [Status pages for enterprise sales](/use-case/enterprise-sales) 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. - [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. ## 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. Try Starter free for 14 days from your billing settings, 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 incident response platform. Monitor from 28 regions, publish a branded status page on your own domain, and manage it from Slack, an [AI agent](/tooling/mcp-server), the dashboard, [CLI](/tooling/cli), [API](/tooling/api) or [Terraform](/tooling/terraform). 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).