Uptimepage

Hi Fazier I built Uptimepage because every status page I tried was either a second tool to wire up next to my monitoring, or a hosted product that put the basics behind a paywall. So the whole thing is one product: the checks that go red are the same ones that drive your public status page, so the page can't lie about being up when it isn't. It's AGPL, the core is free (checks, status page, subscribers, API, every alert channel), and you can self-host the single binary or use the hosted tier. It's driveable by click, REST API, an official Terraform provider, and an MCP server, so you can manage monitors as code or ask an assistant about incidents. I'm doing a founding tier for the first users while we grow. Happy to answer anything, and I'd genuinely like to hear what your status page setup is missing today.

The operational chaos problem Uptimepage solves is real for small teams. Usually you end up with Pingdom or Datadog for monitoring, then a separate status page tool, then manual Slack messages when things break - which means delays, context switching, and customers finding out about outages before the team. Having monitoring and the public status page tightly integrated into one product with unified alerting means the same incident that triggers a PagerDuty alert also automatically updates your customers, disables the incident, and pages the team until acknowledged. The everything-as-code angle (REST API, Terraform provider, MCP server) is especially smart for infrastructure teams - this becomes part of your IaC instead of another manual tool to babysit. The free core features also mean you're not trapped in a pricing tier just to get basic monitoring working.

I like how this combines uptime monitoring with a built-in status page instead of requiring multiple services. The fact that you support multiple monitoring protocols and self-hosting makes it a solid option for developers who want more control over their infrastructure. I'm curious if there are plans to add historical uptime analytics or customizable incident reports.

Really like that monitoring and the public status page share the same source of truth. The Terraform provider + MCP server angle is a nice touch too—teams can treat monitors as code instead of babysitting another dashboard. Curious how scripted browser login checks are priced or limited on the hosted tier?

what a wonderful project, keep it up

The thing I'd want settled before pointing customers at a hosted status page: is the page served from the same infrastructure as the monitoring backend, or is it isolated and CDN-cached so it stays reachable when your own stack has a bad day? A status page that goes down with the thing it reports on is the classic failure mode. Related: can a self-hosted instance push into the hosted status page as a fallback? Leaving checks, subscribers and every alert channel outside the paywall is a rare choice, and it's the main reason I'd try this over monitoring plus a separate status page tool.

I really like that monitoring and the status page are built into the same product instead of feeling like separate services stitched together. The setup seems straightforward, the range of monitoring options is impressive, and having so many alert channels available out of the box is a big plus. The fact that the core features are free and you can choose between hosted or self-hosted makes it easy to try without much commitment.

The part I find most useful is that TLS-cert and domain expiry sit alongside the HTTP checks rather than being a separate reminder somewhere — expired certs and lapsed domains cause a surprising share of real outages and they are usually monitored by nobody. Question on the self-hosted side: when you run probes in your own regions, does the status page still have to be hosted by you, or can it point at a self-hosted probe fleet?

Must be thoughtful, specific, and helpful.

It's a great product with smooth pricing.

Uptimepage has great potential and offers some useful features, but I encountered a few issues that could be improved. Please contact me so I can share detailed feedback and suggest the changes I'd like to see. Email: [email protected]

The fact that the checks and public status page are driven by the same source of truth is compelling. For teams using the self-hosted binary, can incident updates be published through the REST API or Terraform as part of an existing incident workflow? That would make it easier to keep a human-written status update alongside the probe state.