OpenStatus

OpenStatus is an open-source platform that unifies status pages and uptime monitoring in a single deployable system. Engineering teams use it to publish transparent, branded incident communication pages and run continuous synthetic checks against their HTTP endpoints, TCP ports, and DNS records from 28 regions spanning AWS, GCP, and Azure.

Built as a Turborepo monorepo, OpenStatus ships six independently deployable services: a Hono-based API server on Bun, a Go checker for high-frequency probing, a Next.js dashboard, a status-page renderer, a workflow processor for notifications, and a private-location agent that fits in an 8.5MB Docker image for VPC monitoring.

The platform embraces infrastructure-as-code principles with YAML config files, a CLI, GitHub Actions integration, and Terraform support — letting teams version-control their monitoring alongside their application code. Incident notifications reach teams through 14 channels including Slack, Discord, PagerDuty, Telegram, WhatsApp, Twilio SMS, and Microsoft Teams.

Uniquely, OpenStatus ships with a built-in MCP (Model Context Protocol) server, allowing AI agents such as Claude to create monitors, file status reports, and manage maintenance windows programmatically via natural language instructions.

What You Get

• Branded Status Pages - Fully customizable status pages with custom domains, password protection, subscriber notifications via email and RSS, maintenance windows, and real-time incident history displayed to your users.
• Multi-Protocol Synthetic Monitoring - Continuous HTTP, TCP, and DNS checks executed from 28 regions across AWS, GCP, and Azure with detailed per-request timing breakdowns including DNS, TLS handshake, and time-to-first-byte.
• Monitoring as Code - Define all monitors in YAML config files checked into your repository, deploy changes via GitHub Actions or the CLI, and manage monitors the same way you manage infrastructure.
• 14 Notification Channels - Route alerts to Slack, Discord, PagerDuty, Microsoft Teams, Telegram, WhatsApp, Twilio SMS, email, webhooks, OpsGenie, Grafana OnCall, ntfy, and Google Chat with automatic status page updates on trigger.
• Private Location Monitoring - Run an 8.5MB Docker agent inside your VPC to monitor internal endpoints unreachable from the public internet while publishing their status to a public-facing page.
• MCP Server for AI Integration - A built-in Model Context Protocol server lets AI agents like Claude create and manage monitors, file status reports, configure maintenance windows, and query audit logs through natural language.
• Self-Hostable Microservice Architecture - Pre-built Docker images for every component (server, dashboard, checker, workflows, status-page, private-location) deployable via Docker Compose or Coolify with a single config file.

Common Use Cases

• Public SaaS status page - A SaaS company deploys OpenStatus behind status.yourcompany.com with custom branding, showing real-time uptime graphs and incident history so customers can self-serve during outages instead of flooding support.
• Monitoring-as-code in CI/CD - A platform team version-controls 60+ HTTP endpoint definitions in YAML, updates monitor config via pull request, and gets Slack alerts when staging endpoints regress before production deployments.
• Internal API monitoring behind firewalls - A DevOps team runs the private-location Docker agent inside their Kubernetes cluster to monitor internal microservice health endpoints and surface status to a public page without exposing internal infrastructure.
• AI-driven incident response - An on-call engineer connects their Claude environment to the MCP server, asks it to create new monitors, generate a status report for an ongoing incident, and schedule a maintenance window — all without opening the dashboard.
• SOC 2 compliance documentation - A compliance team relies on OpenStatus’s automatic timestamped incident logs and subscriber notification records to satisfy SOC 2 CC2.3 audit requirements without maintaining separate documentation.
• Multi-region latency visibility - A performance team monitors their API from all 28 global regions simultaneously to identify geographic latency regressions before users in specific regions notice degraded response times.

Under The Hood

Architecture OpenStatus is structured as a Turborepo monorepo with six clearly separated deployment targets that communicate through well-defined boundaries rather than shared in-process modules. The API server (Hono on Bun) handles all external client requests and exposes both a REST/OpenAPI v1 surface and a ConnectRPC layer for internal service communication. The Go-based checker runs as an independent microservice responsible solely for executing HTTP, TCP, and DNS probes with nanosecond-precision timing collection, decoupled from business logic entirely. Workflow processing for notifications is isolated in its own service, receiving events rather than being called synchronously, which prevents notification failures from blocking the check pipeline. This separation of concerns is enforced structurally by workspace boundaries in the monorepo, making it impossible for, say, notification logic to import checker internals.

Tech Stack The API server runs on Hono and Bun, providing a fast, type-safe HTTP layer with Zod-OpenAPI for schema-first endpoint definitions and ConnectRPC/protobuf for internal RPC. The checker is implemented in Go using the standard net/http library with custom httptrace hooks for sub-millisecond timing breakdown across DNS, TCP, TLS, and body transfer phases. Data is stored in Turso (libSQL/SQLite-compatible) accessed through Drizzle ORM, with Tinybird providing analytics event ingestion at scale. The dashboard is a Next.js app using the App Router with React Server Components, shadcn/ui for the component library, and Tailwind CSS for styling. Linting and formatting are handled by OxLint and oxfmt, replacing the ESLint toolchain with significantly faster Rust-based tooling across the entire monorepo.

Code Quality The codebase ships with extensive test coverage across all API routes — every CRUD operation on monitors, pages, incidents, and subscribers has dedicated test files using Bun’s native test runner. Tests validate not only success paths but also authentication failures (missing keys return 401), schema conformance (Zod parse success is asserted explicitly), and cleanup after mutation tests. The Go checker package has parallel unit tests for HTTP, TCP, and DNS check logic. Runtime correctness is enforced through Zod schemas on all API request/response boundaries, ensuring malformed payloads fail fast with structured error messages rather than propagating invalid state. Error handling returns typed, HTTP-status-appropriate responses throughout, with Sentry integration for production error tracking.

What Makes It Unique The most distinctive technical decision is the built-in MCP (Model Context Protocol) server, which exposes OpenStatus’s entire operational surface — monitors, pages, status reports, maintenance windows, audit logs — as AI-callable tools. Each request to the MCP endpoint creates a fresh, workspace-scoped server instance, making workspace isolation a structural property rather than a runtime check. The Go checker’s timing model is unusually granular, capturing separate timestamps for DNS start/done, connect start/done, TLS handshake start/done, first-byte start/done, and transfer start/done — giving operators visibility into exactly which network phase caused a latency spike. The private-location architecture (a single-binary 8.5MB image) lets teams run monitoring agents inside air-gapped environments with zero external dependencies while still aggregating status centrally.

Self-Hosting

OpenStatus is released under the GNU Affero General Public License v3.0 (AGPL-3.0). For self-hosters, this means you can freely run, modify, and extend the platform for your own infrastructure use. The copyleft obligation applies if you distribute the software or offer it as a network service to others — in that scenario, you must make the source code of your modifications available. Teams running OpenStatus internally for their own monitoring face no practical restriction on commercial use.

Operationally, self-hosting OpenStatus means running and maintaining up to six Docker services: the API server, dashboard, checker, workflow processor, status-page renderer, and optionally a private-location agent. The Docker Compose setup provided in the repository covers the full stack, and the project publishes pre-built images via GitHub Container Registry for each component. You are responsible for managing the Turso database (or a compatible libSQL instance), configuring environment variables for each service, and handling updates manually by pulling new images or rebuilding from source. The project’s active commit cadence (80+ commits per month) means updates are frequent, so teams should budget time for periodic maintenance.

The managed SaaS tier at openstatus.dev adds a hosted infrastructure layer, professional support, and flat-rate pricing with unlimited team members — a meaningful difference for teams who want guaranteed uptime for their monitoring platform itself. Enterprise customers gain access to higher monitoring frequencies, dedicated support via email, and optional white-glove onboarding. The managed service also abstracts away the operational overhead of maintaining the checker fleet, Tinybird analytics pipeline, and multi-region network infrastructure that the self-hosted stack requires you to replicate on your own.