Building a public status page for client sites

There’s a moment every consultant and managed service provider knows: a client calls to ask if their site is down, you check, it is, and the call becomes two problems — the outage, and the fact that the client found out from their own customers. The status page exists to delete that second problem. HITS Scout publishes public status pages for any set of your monitors — no login required for viewers — and this article is about building one that does its actual job: keeping customers informed before they have to ask.

What a HITS Scout status page is

A status page is a curated, public view over a selection of your monitors. It shows live uptime status, response times, and recent incidents for each monitor you include. Viewers just need the URL — no accounts, no “sign in to see if we’re down”, which is the single most absurd pattern on the modern web.

The key design decision is that inclusion is manual. Your status page is not a dump of every monitor you run — it’s a deliberate subset of the services your audience actually depends on. Internal tooling, staging environments, and the manager’s dashboard that’s always slow don’t belong on it. The page answers one question for one audience: are the things I care about working?

Why the status page outlives your website

Here’s the detail that matters and that most people miss: your status page is hosted on HITS Scout’s infrastructure, not yours. When your primary site falls over entirely — DNS meltdown, host outage, the classic full-fat disaster — the status page keeps serving from wherever it lives, completely indifferent to your misfortune.

This is why the footer link pattern works: put your status page URL in your site footer, your support email signature, your on-hold music if you have it. When things break, the first place customers look still works, still loads fast, and still has your incident history on it. A status page that only works when everything else does is a decoration.

Structuring one for client sites

If you run sites for other people — an agency, an MSP, a consultancy like us — one page per client is the clean default. Each client’s page contains exactly their monitors: their website, their app, maybe their email if you’re watching that too. The client gets a URL they can bookmark and, better, hand to their own customers during an incident. You’ve just given every client a professionalism upgrade they didn’t have to build.

For your own product, structure the page by user-facing service, not by internal architecture. Customers don’t care that “api-cluster-3” is degraded; they care that “Login” and “Dashboard” are affected. Name monitors after what your users experience.

What viewers see during an incident

The incident timeline on a status page is doing quiet, important work: it converts your monitoring data into a story a non-technical reader can follow. An entry that says a monitor went down at 14:32 and recovered at 14:58 is reassuring in a way that “we’re investigating intermittent issues” never is. Specific timestamps read as competence — someone is watching this thing closely enough to know.

Response-time history earns its place on the page the same way. Even when nothing is “down”, a visibly slow week on the graph sets honest expectations and quietly justifies the maintenance you’re about to do.

The trust compounding effect

Most status pages sit empty and green for months, and it’s tempting to conclude they’re doing nothing. They’re doing something slower: every day the page is up and accurate, it compounds a little trust. Customers learn it exists, learn it’s honest (uptime percentages with visible dips are more believable than 99.99% claims with a suspiciously flat graph), and learn that when something breaks, there’s a place to check before opening a support ticket.

When the real outage arrives — and it will — the page converts what would have been fifteen inbound “is it down?” calls into fifteen quiet refreshes. That’s the entire business case, and it’s plenty.

Status pages are available on every HITS Scout plan, including free — hitsscout.link/signup. Set up a monitor, curate the page, put the link in your footer, and forget about it until the day it earns its keep.

Next in this series: multi-region monitoring agents and the cross-monitor activity timeline — catching the incidents that only show up in one region, and the ones that hit three sites at once.

Leave a Reply

Your email address will not be published. Required fields are marked *

WordPress Appliance - Powered by TurnKey Linux