Status Pages Killed 80% of Our "Is It Down?" Emails

Last year I set up something that took under an hour for 20 clients and quietly killed a recurring annoyance I'd lived with for years. I'm writing it down because the numbers genuinely surprised me.

The problem

Every time a client's website hiccuped, or even when something near it did, like their host's network having a rough afternoon, the same email landed:

"Hi, is the site down? A customer just told us they can't reach it."

Or the worse version, after the fact:

"Hi, looks like it's back. Was it down? How long? What happened?"

These ate a stupid amount of time. Not because they were hard to answer, but because they always arrived mid-fix. Context-switching to write a calming email while you're elbow-deep in a server problem is the opposite of productive.

And the "was it down?" version was usually about something I'd already fixed. The client didn't know I'd patched it, because they never knew it broke.

The solution (spoiler: it was embarrassingly simple)

A branded status page for each of my 20 premium clients. Their own domain (status.clientname.com), my agency's logo, wired to the checks I was already running.

Setup: about 3 minutes per client. Add a CNAME, point it at the platform, set the branding, pick which monitors show. SSL gets provisioned for you.

Here's the loop now when something breaks:

1. Monitoring detects the issue
2. Status page updates itself, showing which service is affected and when it started
3. I fix the problem
4. Status page updates itself again when the service recovers
5. The incident stays in the timeline as a record

The client opens status.theircompany.com whenever they want and sees exactly what's going on. No email.

The numbers

I tracked it for three months after rollout. What happened to the "is it down?" emails:

Before status pages: 12-15 per month across all clients.

After status pages: 2-3 per month, and those were from clients who hadn't bookmarked their page yet.

Roughly an 80% drop, for 3 minutes of setup each.

The part I didn't see coming was the goodwill. Clients started saying things like "love that we've got a status page, it makes us look buttoned-up to our own customers." One started sharing the URL with their customers as a quality signal. I'd set these up to save myself emails; they turned into a selling point for the client.

How automatic incidents work

This is what makes it hands-off.

When monitoring confirms a real issue (and "confirms" matters here: the failure gets re-run from a second region before anything posts, so a network blip doesn't fake an outage) an incident opens on the status page on its own. The affected service flips to "down" with a timestamp. I can add manual updates ("Identified, database connection issue, restarting services") but I don't have to.

When it recovers, the incident closes itself with a recovery timestamp and the service goes back to operational. The entry stays in the timeline for the history.

During an incident I do exactly one thing: fix the problem. The page handles the client comms.

The business case

Here's the bit nobody mentions: status pages are nearly pure margin.

The platform charges a flat monthly fee and status pages are included, no per-page surcharge. But I bill premium clients €25-35/month for a "Professional Monitoring" package: monitoring plus their branded page.

20 clients × €30/month = €600/month, against a platform bill of a few euros and zero ongoing time. I didn't plan a revenue stream. I wanted fewer emails. The €600 was a side effect, a good one.

How to set this up

Managing client sites and want the same thing? The exact process:

Step 1: Make sure you're actually monitoring the client's key services: uptime, SSL, maybe DNS and a couple of API endpoints. Not monitoring yet? Start there first.

Step 2: Create a status page. Name it, add the monitors, group them into sections a non-engineer understands ("Website", "Email", "API", not "HTTP check on port 443").

Step 3: Set a custom domain. I use status.clientname.com. Add a CNAME in the client's DNS pointing at the platform's target. SSL is provisioned automatically, no certificate files, no nginx configs to touch.

Step 4: Brand it. Logo, primary colour, a footer with your agency name. The client should see you, not the monitoring tool.

Step 5: Send the URL. "Hey, we've set up a live status page for your services at status.yourcompany.com, check it anytime for current status and incident history."

That's the whole thing. 3 minutes a client, 5 if you have to dig up DNS credentials.

One honest caveat: a status page tells your client that something is down, not why. This is monitoring, not an APM. No traces, no flame graphs. To find the slow query you'll still open your real debugging tools. But for the job of "client checks the page instead of emailing me," it's hard to beat. The first time that happens, you'll get why I wrote a whole post about it.