openstatus: Status Pages and Uptime Monitoring Declared in Code

What openstatus Is and Who Should Deploy It

openstatus brings together two functions that engineers typically wire up separately: uptime monitoring and the public status page that communicates incidents to users. Both live in the same platform, share the same configuration model, and operate from the same API key. The README describes the platform's core positioning as built for infra as code, meaning monitors and status pages are declared as configuration rather than clicked together in a web interface.

The target users are engineering teams that already manage infrastructure as code and want their monitoring layer to behave consistently with the rest of their stack. It also suits teams that want to give an AI assistant direct access to their monitoring workspace: the platform provides an MCP server that Claude, ChatGPT, or Cursor can connect to for read and write operations.

It is available as a managed service at openstatus.dev or as a self-hosted deployment. The self-hosted path is explicitly supported, with Docker images published for each service component.

Monitors and Status Pages Declared in YAML or Terraform

The infrastructure-as-code model is one of openstatus's most distinctive properties. Monitors and status pages can be defined in YAML files and applied from the CLI or from a CI pipeline. The same resources can also be managed through a Terraform provider. This means a team's monitoring configuration lives in version control alongside application code, with the same review and audit workflow.

The README notes that every mutation is recorded in the audit log, which gives teams a traceable history of configuration changes. Notification channels, including Slack, Discord, PagerDuty, email, and others, are part of the same declared configuration.

Status pages support custom domains, password protection, maintenance windows, and subscriber notifications via email and RSS. The platform checks from 28 global regions across three cloud providers, giving teams coverage across geographies without managing probe infrastructure themselves. A private-location container, distributed as an 8.5 MB Docker image, lets teams run probes inside private networks that the managed service cannot reach.

Self-Hosting openstatus with Docker

The recommended path for self-hosting is Docker Compose. The README gives a three-step process:

# 1. Copy environment file
cp .env.docker.example .env.docker

# 2. Start all services
docker compose up -d

# 3. Access the application
open http://localhost:3002  # Dashboard
open http://localhost:3003  # Status Pages

The full Docker Compose configuration runs several services: a libSQL database on port 8080, a Tinybird analytics instance, and the application containers for the dashboard, API, workflows, status pages, and checker. The libSQL service is configured with a maximum of 512 concurrent connections and 1024 concurrent requests, and is memory-capped at 512 MB.

For cloud deployment, pre-built Docker images are published to the GitHub Container Registry:

ghcr.io/openstatushq/openstatus-server:latest
ghcr.io/openstatushq/openstatus-dashboard:latest
ghcr.io/openstatushq/openstatus-workflows:latest

A one-click Railway template is also documented for teams that want to deploy the full stack without managing individual services. The DOCKER.md and COOLIFY_DEPLOYMENT.md files contain detailed setup instructions for each deployment path.

MCP Server and Agent-Driven Incident Management

openstatus publishes an MCP server that connects AI assistants directly to a workspace. Claude, ChatGPT, and Cursor are named explicitly as supported clients. The MCP connection accepts both read-only and read-write API key scopes, giving teams control over what an agent is allowed to change.

The CLI also supports a `--json` flag for machine-readable output, which makes it suitable for scripted agent workflows beyond MCP. The README describes the full tooling suite as the API, CLI, Terraform, and MCP server, all sharing a single API key.

This design reflects a broader trend in infrastructure tooling: making systems operable by automated agents rather than only by humans clicking through dashboards. For teams that use AI coding assistants with tool access, the MCP integration means status and monitoring data is reachable from inside the same conversation where application code is being written.

Coverage Limits and the AGPL-3.0 Constraint

The AGPL-3.0 license is the most significant operational constraint for teams considering openstatus. The Affero GPL requires that any entity running a modified version of the software over a network must make its source code available to users of that service. For internal tools this is often manageable, but teams building commercial products on top of openstatus need to review whether their use case triggers the disclosure requirement.

Private-location monitoring covers probes inside private networks, but the location runs as a container that the team manages. This means the team is responsible for the container's uptime, network connectivity, and updates. The README does not document how many private-location containers are supported per workspace or how they communicate back to the central service.

The tech stack for a manual self-hosted setup requires Node.js, pnpm, Deno, and the Turso CLI. The presence of multiple runtimes and external services means a fully self-hosted deployment has more moving parts than a simpler single-process tool.

openstatus vs. Atlassian Statuspage

Atlassian Statuspage is a hosted status page service that many engineering teams use to communicate incidents. It does not include uptime monitoring as a native feature, so teams typically combine it with a separate monitoring tool such as Datadog or PagerDuty.

openstatus differs in two ways. First, it combines monitoring and status pages into one tool, which reduces the number of integrations required. Second, it is self-hostable and open-source, which matters for teams with data residency requirements or cost constraints. Atlassian Statuspage charges per subscriber for subscriber notification tiers. openstatus uses flat pricing with unlimited members, according to the README.

The trade-off is operational complexity. Atlassian Statuspage is a managed service requiring no infrastructure management. openstatus self-hosting requires maintaining the container stack. Teams who cannot or do not want to manage that infrastructure can use the openstatus managed service instead, but they then give up the control that is usually the reason for choosing a self-hosted option.

Maintenance and Tech Stack

The last push was on 2026-09-27. The project is under active development. The repository has no GitHub releases tagged, so there is no version-pinned release history in the conventional sense.

The tech stack is documented in the README: Next.js for the dashboard, Hono for the API server, Go for the checker service, Turso for the database, Drizzle as the ORM, Tinybird for analytics, and Tailwind CSS with shadcn/ui for the interface. This is a substantial stack, and self-hosters should account for the operational overhead of understanding and maintaining each component.

The AGPL-3.0 license permits unlimited use, modification, and distribution, subject to the source-disclosure requirement for networked services.

Editorial conclusion

openstatus is the right choice for engineering teams that want status pages and uptime monitoring under a single configuration model they control, with self-hosting as a first-class option. It is not the right choice for teams that need a permissive open-source license: the AGPL-3.0 requires that any networked service built on it distributes its source code. Teams evaluating it should verify that the private-location Docker image covers their network topology and that the required external services (Turso, Tinybird) fit their infrastructure policy before committing to a self-hosted deployment.

Frequently asked questions

Official sources

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