OpenStatus

What OpenStatus is

OpenStatus pairs the two halves of incident communication that normally live in different products. One half watches your servers, websites and APIs and tells you when they are down or slow. The other half is the public page your customers open to find out whether the problem is you or them. Most small teams end up paying for a monitoring service and a status host separately, then keeping them aligned manually. OpenStatus ships both under AGPL-3.0, and lets you run the whole thing yourself if you would rather not depend on one vendor to announce that another vendor is fine.

The project started in June 2023 and is genuinely active — at capture the most recent commits were from the previous day, including a hardening pass that blocks private address ranges in monitor URL validation. It is a TypeScript monorepo: a Next.js dashboard, a Hono API server and a checker written in Go, with Turso, Drizzle and Tinybird underneath. Worth knowing before you plan an upgrade path: there are no tagged GitHub releases. The project ships from its main branch and publishes pre-built container images instead, so you pin an image digest rather than a version number.

What you get out of the box

The README is specific about the surface, which makes it easy to check against what you actually need:

• Status pages Custom domains, password protection, maintenance windows, and subscriber notifications over email and RSS. The hosted plan is priced flat with unlimited members rather than per seat or per subscriber, which is worth noting because this category has traditionally billed you by the number of people who want to know when you are down.
• Checks from 28 regions Monitors run in parallel from 28 regions across three cloud providers. A single-region checker will eventually tell you your site is down when what actually happened is that one region is unhappy, and you will find that out at 3am.
• Monitoring as code Monitors, notifications and status pages can be declared in YAML, driven from the CLI, run inside GitHub Actions, or managed with Terraform. If your infrastructure already lives in version control, the checks can sit next to it and get reviewed the same way.
• Alerting, an API, and an MCP server Alerts route to Slack, Discord, PagerDuty or email. On top of that there is a typed JSON-over-HTTP API with a Node SDK, a CLI with a `--json` mode aimed at agents, and an MCP server so an assistant can query the workspace directly instead of scraping a dashboard.
• Self-hosting A Docker Compose file brings the stack up locally, and there are published images plus a Coolify deployment guide. Private locations — checks that run inside your own network against things the public internet cannot reach — ship as a single 8.5MB image.

What it is not: OpenStatus watches endpoints, not application internals. It answers whether the thing your customer touches is responding and how fast, not why it stopped. Tracing and log aggregation are a different category of tool, and the project does not pretend otherwise.

Where it fits a founder's growth stack

A status page is not an acquisition channel and it is worth saying so plainly — it will not bring you traffic. What it does is remove friction at two specific moments: when a prospect is deciding whether you are a real company, and when an existing customer is deciding whether to email you or wait five minutes. Both are trust work, closer to social proof than to marketing. The same instinct that makes Documenso worth running applies here — the artefacts that make a small company look accountable are cheap to operate and expensive to be caught without.

The trigger to set one up is your first paying customer, not your first outage. A status page created during an incident is a page nobody has subscribed to, on a domain nobody knows, written by someone who is currently very busy. The setup is an hour of work whose entire value depends on it predating the thing it exists for. If you sell to developers there is a second reason: a status page and a changelog are two of the small handful of pages a technical buyer goes looking for unprompted, alongside your documentation. More on that audience in how do I market a developer tool.

What we learned pointing a checker at our own fleet

This part we can add from operating rather than from reading. AgentCeres — the AI Growth Officer at agentceres.com — runs a separate container per customer workspace, and idle ones scale to zero to keep the hosting bill sane. That makes "not responding" and "asleep" two different states, and it broke our monitoring instincts twice. First, a probe is not free: every check against a scale-to-zero service wakes it, so the monitor pays for the cold start and quietly erases the saving it was hired to watch over. We eventually traced one workspace that was awake essentially all the time to a forgotten logged-in browser tab polling a background endpoint every few minutes, while the rest of the fleet idled in the single digits. Second, our own health checks had to learn to report "sleeping" without probing at all — a sentence that only makes sense once you have decided what "up" means for your particular architecture.