What to Include in a Client-Facing Status Page

A status page per client sounds like an enterprise affectation until the first time a client emails "site's down?" at 7am and you answer with a link instead of a panic. Then it becomes the best piece of client UX you ship. The trick is that a client-facing status page is not the same artifact as the internal dashboards ops teams use — it needs much less, presented much more carefully.

Include these

Current status, unmissable. A big green "All systems operational" (or an honest red) at the top. This is the only thing most visitors came for; it should be readable from across the room.

One row per service the client recognises. "Marketing website", "Online store", "Booking form" — named in the client's language, not yours. A client doesn't know what api-eu-prod is and shouldn't have to.

Uptime over a meaningful window. 24 hours, 7 days, 30 days. Percentages build trust precisely because they're not always 100% — a page showing 99.97% reads as measured; a page that only ever says "up" reads as decorative.

Recent incident history, with duration. "Outage — 14 minutes — resolved" tells the story you want told: things occasionally break, and they get fixed fast. Hiding incidents is counterproductive; the client noticed anyway, and the status page that admits it earns the benefit of the doubt next time.

Your branding. Your name, your colours, your logo. The page is part of the service the client pays you for. If it advertises a monitoring vendor instead, it's telling the client where to go to cut out the middleman.

Leave these out

• Response-time internals, server metrics, check logs. Signal for you, noise for them — and every extra number is a potential "should I be worried about this?" email.
• Other clients. One page per client, always. A shared page leaks your client list and everyone else's bad week.
• Jargon. "Degraded performance on the origin" helps nobody. "Site is slower than usual — we're on it" does.

Password-protect the sensitive ones

Some clients are fine with a public page; some (internal tools, pre-launch sites) shouldn't be visible to anyone with the URL. The page should support both — public by default, password-protected when the client's business calls for it.

The ten-minute version

This is exactly the shape of the per-client status pages UptimeDesk generates: live status from 60-second checks, uptime over three windows, incident history with durations, your branding, optional password. Create a client, share the link, done — there's a live example here. What matters is that the page exists before the next 7am email does.