Status Pages: Why Every Client of Your Agency Should Have One

When a big service has a problem (GitHub, Slack, a payment provider), nobody calls support. You open status.github.com, read "we are investigating an issue", and wait. That page is called a status page, and it's the cheapest way there is to answer a thousand people at once without answering any of them individually.

The reason it's worth having one even for a twenty-page brochure site isn't scale. It's that the problem it solves, "the client doesn't know what's happening and calls you", is identical, just with smaller numbers.

What a status page is, in practice

It's a public page, separate from the site it monitors, that says three things: whether everything is working right now, how the last few months have gone, and whether there have been any recent outages. Nothing else.

It lives at an address different from the site's, usually a subdomain like status.clientname.com, precisely because it has to stay reachable when the site isn't. A status page hosted on the same server as the site it monitors is a contradiction: it goes down along with it, at exactly the moment it's needed.

Why a small online shop needs one as much as a big service

The difference between GitHub and your client's online shop isn't the kind of problem, it's how many people notice it in the same minute. The question they ask is the same: is it broken for everyone or just for me, and is anyone dealing with it? And for your client (the owner opening the site on their phone, the salesperson with a customer waiting, whoever can't complete an order) there is currently only one way to get an answer: call you. Even when the problem was fixed ten minutes ago.

What changes for the client: fewer phone calls, not more

The most common worry when you propose a status page is that giving the client one more tool means giving them one more reason to write to you. The opposite happens, for a simple reason: the phone calls during an outage don't come from the problem, they come from the silence. Someone who sees "outage in progress, started at 2:32 p.m." already knows the two things they wanted to know: it isn't their fault, and someone is looking at it.

There's also a less obvious side effect: the status page defuses false reports. The "the site isn't working" message that lands on a Tuesday morning and turns out to be the wi-fi in the client's office still costs you half an hour of checking. A page that says "all services are operational, last check at 9:41 a.m." settles the matter before it reaches you.

What changes for you: visible proof of invisible work

This part is about your margin more than the service.

Almost everything you bill as maintenance is invisible by definition: a backup done well isn't visible, a security update applied in time isn't visible, an abandoned plugin replaced before it becomes a problem is especially not visible. That's why the "maintenance" line is the first one the client tries to cut at renewal: not because it isn't worth it, but because they've never seen anything that represents it.

The status page is the exception. It's the only artifact of your maintenance work that the client can open whenever they like, with your logo on top, showing them ninety-nine point something percent uptime over the last three months. It isn't a report you sent them: it's a page that updates itself. And that's exactly why it's credible.

Why it must live on the client's domain, not the tool's

A status page at the address generic-monitoring.com/pages/12345/client-smith does its technical job and gets everything else wrong. It tells the client there's a supplier in the middle they knew nothing about, moves trust from your brand to a brand they didn't choose, and puts you in an awkward position the day you change tools.

On a domain you control, status.clientname.com via a CNAME, or status.youragency.com if you prefer to gather all your clients under your own brand, the page is yours in every respect: logo, colors, footer text. The HTTPS certificate for that subdomain must be issued and renewed automatically, otherwise you've created in-house exactly the problem you're selling a fix for.

What to put on it (and what to leave off)

A useful status page has three blocks and stops there:

The verdict right now. A single line: everything operational, or outage in progress. With the time of the last check, which is what makes the rest credible: "all operational" with no time next to it means nothing.

The history. One bar per day over the last ninety days: green when the day was clean, yellow when a few checks failed, red when it really went badly. It's the block the client cares about least at the moment of an outage and most at renewal time.

Past outages, with start date, end date and duration. An honest list of three lines does more for trust than a page that's always perfectly green, which simply doesn't look real.

What to leave off: everything else. Error codes, latency charts, server names, infrastructure details. They're no use to the reader and turn a reassuring page into a worrying one.

The detail that decides whether the page helps or hurts

A status page is public: whatever ends up on it is public. A slowdown isn't an outage: if the site responds in three seconds instead of half a second, that's a problem for you to look at, not an alarm to show the client. And a single failed check isn't a down: if the page declares "outage in progress" because one check came back empty due to a network problem on the checker's side, you've scared the client for nothing, and the time they write it for real, nobody will believe it.

The practical rule is just one: only what's been confirmed from more than one observation point goes on the public page. Everything else stays in your dashboard, where it's useful to you. Which response times make sense to promise on top of this data is the subject of the article on web agency SLAs.

The status page Statuo generates

In Statuo the status page isn't a module to configure: it's what you get by choosing which sites to group on a page. Pages are unlimited on every plan, one per client or a single one for a group of sites, and the name the client sees can differ from the one you use in the dashboard.

On it you get exactly the three blocks described here: the current verdict with the time of the last check, daily bars and uptime percentage over the last ninety days, and a list of the latest outages with start, end and duration. It updates itself every minute, it's plain HTML (no JavaScript required), it's kept out of search engines, and it shows the per-region breakdown ("Europe · Italy", "North America · USA", with the latency from each) only when more than one location is active. Slowdowns don't appear: they stay visible only to you in the dashboard. And an outage is opened only after confirmation from two different locations.

A note of honesty, because it matters more than the feature list: the outages are written by the system, with times and duration calculated. There's no field (for now) to add an explanation by hand, such as "cause: scheduled maintenance by the provider". The page says what happened and how long it lasted, not why: if you want to tell the client that, it stays an email from you.

The custom domain, status.clientname.com via CNAME, with the HTTPS certificate issued and renewed automatically, is included from the Agency plan up. Logo, color, footer and the "Powered by Statuo" label (which you can remove) are set once for the whole agency; the language is chosen page by page from Italian, English and Spanish, with times in the viewer's time zone.

The fastest way to find out whether your clients need one is to put one in front of one of them: the free trial lasts 14 days, with no credit card. Plans are on the pricing page.