openstatus: status pages and uptime checks from one repo

The gap openstatus is trying to close

Most teams end up with two systems: a status page that a human updates during an incident, and a separate synthetic monitor that knows whether the service is actually up. The README frames the pitch directly, calling openstatus a platform that combines status pages and uptime monitoring in a single tool, so there is no need to wire up a separate monitoring service. The intended user is an SRE or platform engineer at a company small enough that nobody wants to maintain that wiring. The project also targets people who prefer to declare monitors in files rather than click them into a dashboard. The README lists monitoring as code with YAML, a CLI, GitHub Actions and Terraform, and the topics list includes both monitoring-as-code and terraform. That is the audience: teams who already keep infrastructure in Git and want their uptime checks to live there too.

What actually runs: checker, API, workflows, status page

The self-hosting section names six container images published to GHCR: openstatus-server, openstatus-dashboard, openstatus-workflows, openstatus-private-location, openstatus-status-page and openstatus-checker. That list is the clearest view of the architecture in the supplied material. The checker is written in Go, according to the tech stack section, while the API server is Hono and the dashboard is Next.js. Turso is the database, Drizzle is the ORM, and Tinybird handles analytics. The README describes private locations as running in a single 8.5MB Docker image, which is the piece that matters if your services sit behind a firewall and you cannot let a hosted prober reach them. The checker image is separate from the private-location image, so there is a distinction between the regions openstatus operates and the probes you run yourself. The README does not spell out how the checker hands results to the API or how Tinybird is populated, so treat the data flow as documented at a high level only. The hosted offering claims 28 global regions across three cloud providers; the self-hosted path does not automatically give you those regions.

Getting it up with Docker, and the manual path

The README calls Docker the recommended route for both development and self-hosting. Three commands: copy .env.docker.example to .env.docker, run docker compose up -d, then open http://localhost:3002 for the dashboard and http://localhost:3003 for status pages. Two ports, two apps, one compose file. If you would rather not run compose, the README points at a Coolify deployment guide and a Railway template that deploys the dashboard, status pages, API, workflows, probes, libSQL and Tinybird Local into one project. The manual route is heavier. The requirements list Node.js 20 or newer, pnpm 10.26.0 or newer, Bun, Deno and the Turso CLI, and the dashboard has its own README under apps/dashboard covering environment variables, database setup, login and troubleshooting. Status pages alone can be started with pnpm install followed by pnpm -w dev:status-page. Note the toolchain breadth: Bun and Deno both appear in the requirements, which is a real cost if your build images are minimal.

One API key across CLI, Terraform and MCP

The tooling section makes a claim worth taking literally: everything the dashboard does is reachable from your terminal, your infrastructure code and your AI assistant, all sharing a single API key. Four surfaces are listed. The API is described as typed JSON over HTTP using ConnectRPC, with a separate Node SDK repository. The CLI is interactive for humans and supports --json for agents, plus YAML monitoring as code. Terraform covers monitors, notifications and status pages as HCL. The MCP server connects Claude, ChatGPT, Cursor or any MCP client to a workspace. The design intent is that you can create a monitor once and manage it from whichever surface your team already uses. The practical consequence is that the API key becomes a shared credential with broad reach across monitors, notifications and status pages, so its handling deserves more care than a read-only token would. The README does not describe scoped or per-surface keys, so assume one key with the full surface area until you check the docs.

Where it stops being the right tool

The dependency footprint is the first limitation. A working self-hosted install needs a database (Turso or libSQL) and an analytics store (Tinybird, or Tinybird Local in the Railway template). That is two stateful services behind a status page, before you count the checker, workflows and dashboard containers. For a five-person team that wants a static page saying whether the API is up, this is a lot of moving parts. The second limitation is the licence. AGPL-3.0 is a strong copyleft licence, and the README states it plainly, so anyone planning to modify the dashboard and expose it to users over a network should read the terms rather than assume. That is not legal advice; it is a reason to get advice. The third is the region claim. The 28 regions belong to the hosted product. Self-hosting gives you whatever probes you deploy, and the private-location image is the mechanism for that, not a substitute for global coverage. Fourth, the README does not describe alert routing logic, retry behaviour or how false positives are suppressed, so if your on-call rotation is sensitive to noise, that is an unknown until you read the docs.

Compared with running a status page and a monitor separately

The obvious alternative is a dedicated synthetic monitoring service for the checks and a separate status page product for the public page. That combination is mature and each half is deeper than openstatus is likely to be in its own specialty. The difference in approach is where the data lives. With two products, an incident in the monitor does not automatically become an incident on the page; someone or something has to bridge them, usually a webhook and a small script. openstatus makes the status page a first-class output of the monitoring data, which is why the repository ships a status-page image and a checker image rather than one app. The second alternative is to keep the status page and drop the monitoring, using a static site plus manual updates. That is cheaper to run and has no database to back up, but it puts the accuracy of the page on whoever remembers to update it. The trade you are making with openstatus is operational surface area in exchange for the two halves sharing a schema.

Maintenance, upgrades and what the licence asks of you

Nothing in the supplied material describes a release cadence, and no recent releases were retrieved, so there is no basis for judging how often you will be pulling new images. What the material does show is the upgrade shape: six published images tagged latest, a compose file, a Turso or libSQL database and a Tinybird instance. Upgrading means coordinating image pulls against schema changes in the database, and the Drizzle ORM in the stack suggests migrations are part of the repository. The README does not document a migration command, so find that before you run an upgrade against production data. On the licence, AGPL-3.0 governs the code in the repository. If you self-host an unmodified build for internal or public use, the practical obligation is the usual one of preserving notices and making source available to users who interact with it over a network. If you fork the dashboard and change it, the copyleft reach is wider. Check that against your own distribution model rather than relying on a summary.

Editorial conclusion

Adopt openstatus if you want the status page and the uptime checks to share one data model and one API key, and if you are willing to run Turso and Tinybird alongside it. Do not adopt it if you only need a public status page, because you would be carrying a checker, a workflows service and an analytics store for nothing. Before you commit, read DOCKER.md and COOLIFY_DEPLOYMENT.md, confirm which of the six published images you actually need, and check whether the AGPL-3.0 terms fit how you intend to expose a modified dashboard.

Official sources

1. Issues
2. License: AGPL-3.0
3. openstatusHQ/openstatus on GitHub
4. Project website
5. README