Uptime Kuma status pages your customers will actually read

• Show services, not servers
• Monitor from the outside
• Host it somewhere else
• Pick sensible intervals
• Write incident notes
• Maintenance windows
• Branding and domain
• Review history monthly
• Keep alerts separate

Uptime Kuma is usually set up for internal alerts, but it also includes public status pages. A good status page reduces support tickets during outages. A bad one, with forty cryptic monitors, confuses everyone. Here is how to build the first kind.

§Show services, not servers

Customers care about “Dashboard,” “API” and “Email delivery,” not web-02 or redis-queue. Create monitors for user-facing functions and group them on the status page accordingly. Keep internal monitors off the public page.

§Monitor from the outside

A status page monitor should test what a customer experiences: an HTTPS request to the real domain, checking for a keyword on the page or a 200 from a health endpoint. Monitoring an internal container IP can show green while DNS or TLS is broken.

§Host it somewhere else

If the status page runs on the same server as the app, it goes down with it. Run Uptime Kuma on a separate small VPS or a different provider, with its own domain such as status.example.com.

§Pick sensible intervals

A 60-second interval with two or three retries before marking a service down avoids flapping on a single slow response. The page then reflects real incidents.

§Write incident notes

Uptime Kuma lets you post incident messages on a status page. Keep them short and factual:

• What is affected
• When it started
• What you are doing
• When the next update will come

Update every 30 minutes during an incident, even if nothing changed. Silence feels worse than “still investigating.”

§Maintenance windows

Schedule maintenance in Uptime Kuma before planned work. Monitors pause, and the status page shows the planned window instead of an outage.

§Branding and domain

Add your logo, a short description and a link back to support. Set up the custom domain with HTTPS through your reverse proxy.

§Review history monthly

The uptime percentages per service tell you where reliability work pays off. One flaky service usually accounts for most of the red.

§Keep alerts separate

Internal alert notifications and the public page are different tools. Customers should not see every warning your team sees.

Installation, notification channels and backups are covered in this guide to self-hosting Uptime Kuma.

Disclosure: I help build Peon.