USE CASE · Self-hosted operations
Self-hosted Uptime Monitoring
When you do not want a third party to know which services you run, when your monitoring tool needs to be on a different failure domain than the things it watches, or when 'managed' costs more than a half-day of ops time per month.
What good looks like
Your checks and dashboards run on a small box you control. The public status page — the only piece your customers ever see — runs somewhere else, on infrastructure that is independent of everything you self-host. A failure in your stack takes the services down; the status page stays up and tells the truth.
What goes wrong without one
Your self-hosted monitoring stack is the most ironic thing to take down. When the box dies, you cannot tell your customers that the box is dead — you are the box.
What this workload actually needs
HTTP/HTTPS on every customer-facing service. TCP on every backend service they care about. A public status page on infrastructure that is not the same box as the monitors. If the page is on the same box, you have just moved the single point of failure from 'the service' to 'the service and the status of the service'.
Rollout checklist
- 01Pick a status page host on a different provider from the rest of your stack. AWS monitors, Cloudflare status page. GCP monitors, Render status page. The point is the failure domain is separate.
- 02Use the smallest possible surface. A status page is not a control panel; it is a sign. If you find yourself wanting to put an interactive debug tool on the page, the page is the wrong place.
- 03Decide who can publish a post-mortem. The answer is the same people who can write a status message. Anyone else should be told on Slack, not on the public page.
- 04Set the check interval to match your incident response time. If you fix things in 5 minutes, a 5-minute check is fine. If you fix things in 30 minutes, a 1-minute check is noise.
Set up a self-hosted uptime monitoring status page in two minutes.
Free plan. No card. Cancel any time.