openstatus

What openstatus does

openstatus combines three jobs that are often bought separately: uptime monitoring, a public status page and incident response. Monitors can make HTTP requests or test TCP, DNS, ICMP and gRPC endpoints. On the hosted service each check can run in parallel from up to 28 regions spread over Fly.io, Railway and Koyeb, so a failure in one region is not mistaken for a global outage and latency is measured where your users are.

The project describes itself as built for infrastructure as code. Monitors, status pages and notification channels can be written in YAML or Terraform and applied from the CLI or a CI pipeline, and everything the dashboard does is also exposed through a typed API, a Node SDK and an MCP server, so a coding assistant can create monitors or post incident updates with a scoped API key.

Status pages and incidents

Status pages support custom domains, password protection, maintenance windows, themes and translations, and visitors can subscribe to updates by email, RSS or webhook. Incidents have a severity (critical, major or minor), an incident commander and a timeline that records every change from open through mitigated to resolved. You can run them from the dashboard or by mentioning the openstatus agent in Slack, and link a status report so the public page shows what the team is doing.

Alerts go to Slack, Discord, email, Microsoft Teams, Google Chat, Telegram, WhatsApp, PagerDuty, Opsgenie, Grafana OnCall, ntfy or a webhook with a documented JSON payload. If you are moving from Atlassian Statuspage, Better Stack, Instatus or Checkly, an importer brings over components, incidents, maintenances and subscribers.

Self-hosting openstatus

The repository includes a Docker Compose setup, prebuilt images on GitHub Container Registry and a Helm chart for Kubernetes. The full stack is several services: the Next.js dashboard and status page, an API server, a workflows service for background jobs, an ingest server for probe results, a libSQL database and Tinybird Local for analytics. Setup needs the Tinybird CLI, and login works by magic link, so a Resend API key is required. Without Tinybird the application runs but charts and analytics do not.

The most important difference from the hosted version is stated plainly in the documentation: self-hosted openstatus works only with private locations. The public probe network is not available, so you deploy the probe container (an 8.5 MB image) on servers, cloud regions or a Raspberry Pi wherever you want checks to come from. The same probes let the hosted service monitor internal systems. The guide also warns that status page IP restriction trusts the X-Forwarded-For header and is only safe outside Vercel if your reverse proxy rewrites it. If you only need a status page, a lighter setup runs four services without Tinybird, probes or the API server.

Hosted version

openstatus.dev offers a free Hobby plan with one monitor, one status page and a ten-minute check interval, plus paid plans with more monitors, shorter intervals, more regions per monitor and longer data retention. Plans include unlimited team members. Private locations, OTLP export and the audit log are on the higher plans, and SSO/SAML and white labeling are paid add-ons.

Limitations

Self-hosting is a multi-service deployment with external dependencies, and you must run your own probes to get checks from more than one place. openstatus watches endpoints from the outside; it does not collect server metrics, logs or traces. The many extras on the hosted plans show where the company earns its money, although the code itself is AGPL-3.0 throughout.

Who it suits

openstatus suits SaaS and API teams that want a public status page with real incident handling and checks from many regions, and that like keeping monitors in Git. Most will use the hosted service; teams that must keep everything in-house can self-host with private probes. For simpler single-server monitoring, Uptime Kuma or Gatus are lighter.