Build the Uptime Status Page That Answers Clients Before They Ask

The Gap Between "Up" and "Working"

Before talking about pages, it's worth being precise about the wrong kind of uptime. An HTTP check that returns 200 tells you the server answered. It doesn't tell you the homepage rendered, the login form works, or the site isn't showing a database error to every visitor. An agency that points a monitor at a URL and calls it done will report Operational while clients stare at a broken screen. That lie is worse than no page at all, because the page is now visible evidence that you don't know what's happening.

The checks need to verify content, not just response codes. Ask the monitor to look for a string that appears on every page, or to complete one simple flow. That catches the outages that matter and ignores the ones that don't.

Yet even perfect monitoring leaves a gap open. The best checks in the world produce alerts that land in your inbox. They do nothing for the client's customers, who have no reason to wait for your alert before asking what's wrong. The status page is the bridge across that gap, and it's the one part of uptime tooling the client can actually see. Treat it that way, or it becomes just another dashboard nobody reads.

The First Ten Minutes, Step by Step

Here is the sequence that makes the difference, run start to finish.

1. The check fails twice before it is trusted. A single missed request can be a network blip, so the monitor waits for a second failure before it says anything.
2. The alert reaches the person who can act. That means a human on call, reachable by chat and email. A shared inbox that gets opened at lunch doesn't count.
3. The status page flips to Investigating with a short note, something honest like "We're looking into errors on the homepage."
4. The page updates as the incident moves, marking each phase: Identified, then Resolved, with a timestamp and a sentence about the cause.

The order matters because the client's customers hear the first word from you. The first word shapes how they read everything after. When the client does hear about it, they already have a page to point people at. And when it's over, the page has written most of the explanation for you.

What Should a Client Status Page Include?

A good client status page answers two questions at a glance: is anything wrong right now, and how does the history look if something was? Everything on the page should serve one of those.

Start with the overall state at the top, in plain words: Operational, Degraded, or Down, and skip the traffic-light icon that means nothing without a legend. Below that, list the components that matter to the client's business: the public site, the admin area, checkout if there is one. Then comes the incident timeline, where each event shows how it moved from Investigating to Resolved, and when. A 30-day or 90-day uptime figure gives the history a number, and a subscribe option, by email or chat, saves the client's team from polling the page.

Branding matters more than it should: put the client's name and colors on the page, because to the client's customers that page is the client's page. An agency-branded outage page reads as an outsourcing disclosure at exactly the wrong moment.

Public or private is a real choice, and it can change over time. A private page still spares the client's team from asking you. A public one spares the client's customers from asking anyone. Most agencies end up public for the sites with real traffic and private for everything else.

The Open-Source Status Page Tradeoff

Open-source status pages are a genuinely reasonable route, and they come up often enough to deserve a straight answer. Projects like Cachet give you a self-hosted page, and Upptime runs one off GitHub Actions with the history living in a repository. For a single service, that's a fine trade: the page is yours to control completely.

For an agency, the math changes with the client count. Every self-hosted page becomes a service you operate: a domain to renew, TLS to keep current, a database to back up, and no SLA of its own. You need the same patch discipline you apply to client sites, and a self-hosted page is exactly the kind of thing that gets skipped when the week goes sideways.

Open source still has a place in the stack. The cost just needs to be counted honestly. If the page is the project, self-host it and enjoy the control. If the page is a means to an end, let someone else run it and spend the saved hours on client work.

What Changes When Clients Stop Asking

The change you notice first is quiet: the messages stop. Sites still go down, but the forwarded "are we down?" screenshots thin out fast. Clients check the page, their customers check the page, and the few who still write in get pointed at it. The question dies there.

The longer-term change is better: at quarter's end, the status page history is a legible record of every incident, its duration, and its resolution. That record is worth more than a dashboard screenshot in a monthly report, because it's already arranged as a story. The day the client forwards your status page to their own customers, you stop being the vendor who has to explain the outage and become the team that already handled it.

Left as things are, the second clock keeps winning: the client's customers keep finding outages first, and the client keeps learning about their own site from the people who visit it. That pattern costs more than uptime; it costs the sense that you're on top of things, which is hard to rebuild inside a renewal conversation.

The first step is small. Pick one client, the one whose site would hurt most if it went down unnoticed, and give them a page worth checking. Monitoring alone won't do it; the page has to exist, stay current, and look like theirs.

If you'd rather not assemble that yourself, Steerpod runs uptime checks every minute and publishes a branded status page per client, so the alert and the page stay in sync. It's free to try. Register at https://steerpod.com/register.