Most status pages are built for the wrong audience. They are written as engineering artefacts — component names, error codes, "investigating elevated error rates" — and then a shop owner wonders why customers keep emailing "is the site down?" while a page exists that answers exactly that question.
A status page has one job: when something is broken, a worried customer lands on it, understands within three seconds whether their problem is your problem, and closes the tab feeling informed rather than ignored. The five examples below are the patterns that do that, ordered from the simplest to the most involved. Copy the one closest to your situation.
Example 1 — the single shop
Who it is for: one website, one product or service, one person who fixes things.
What it looks like: a single banner at the top — green and confident on a normal day, amber or red during an incident — followed by a list of three or four checks in plain language.
- Online shop — up, 210ms
- Checkout and payments — up, 340ms
- Order emails — up
Why it works: the names are customer words, not system words. "Checkout and payments" tells a shopper whether their failed card is your fault. "api-prod-02" tells them nothing.
What to leave out: uptime percentages measured to two decimal places on a page nobody visits on a good day. Put the number in a small corner if you like it; lead with the banner.
Example 2 — the clinic or booking business
Who it is for: a business whose site exists to take appointments, where a down booking form means a ringing phone.
What it looks like: a status page that leads with what customers can do right now, not with what is broken.
Appointments are temporarily unavailable. Phones are answered as normal on 555-0134 during opening hours, and we will book you in manually. We are working on it and will update this page within 30 minutes.
Why it works: it converts a dead end into an alternative route. The customer's real goal was an appointment, not a website, and this page gets them one.
Add: a timestamp on every update, and a line saying when the next update will come. "Updated 14:20. Next update by 14:50." A page that says "we are aware" with no time on it reads like nobody is home.
Example 3 — the small SaaS or app
Who it is for: a product with logged-in users and a handful of moving parts, where different customers hit different breakages.
What it looks like: grouped components with individual states, so a customer can see that their part is fine.
| Component | Status | Last 30 days |
|---|---|---|
| Web app | Operational | 99.99% |
| Payments | Degraded — slow responses | 99.91% |
| Email notifications | Operational | 100% |
| Mobile API | Operational | 99.97% |
Why it works: granularity turns a vague worry into a specific answer. It also protects you: when a customer reports "everything is broken" during a payments slowdown, you have a shared, timestamped record of what actually happened.
Add: an incident history with a short post-incident note. Two sentences — what happened, what changed — do more for trust than a polished apology.
Example 4 — the agency with client pages
Who it is for: a studio or freelancer watching a dozen client sites.
What it looks like: one page per client, on the client's own domain, in the client's colours, with the agency's monitoring behind it. No shared "all our clients" page — that would be a directory of outages with your name on it.
- One page per client, at status.clientdomain.com
- The client's logo, not yours
- The client's support address as the escalation path
- A monthly PDF report per client, showing uptime and response time
Why it works: it makes the retainer visible. A status page and a monthly report are the two artefacts a client actually looks at, and both are cheap to produce once the monitoring is in place.
Watch out for: alert routing. One client's outage should never page another client's account manager, and a shared inbox is the fastest way to make sure it does.
Example 5 — the one-person consultancy
Who it is for: someone whose "site" is mostly a calendar link and a contact form.
What it looks like: the smallest possible version — a status badge embedded in the footer of the site itself, linking to a hosted page. No separate brand, no separate domain.
All systems operational · service status
Why it works: it costs nothing to maintain and it is honest. If the site itself is down, the footer badge goes down with it, but the hosted page stays up and that is exactly where a worried visitor will look.
The wording that does the work
Across all five examples, the language matters more than the design. A few rules that hold universally:
- Name things the way customers say them. "Checkout", "booking", "the app" — not service names or server names.
- Always timescale your updates. "Investigating" alone is an empty sentence. "Investigating, next update by 15:10" is a promise someone is keeping.
- Say what still works. During a partial outage, the most useful sentence on the page is the one listing the paths that are unaffected.
- Write the incident update before you need it. A pre-written template for your three most likely failures saves ten minutes at the worst moment.
- Close incidents properly. Resolved, what caused it in one clause, what you changed. Then leave it in the history.
Incident update template
Status: Investigating / Identified / Monitoring / Resolved
Time: 14:02 (your time zone)
What customers see: Checkout is failing at the payment step.
What still works: Browsing and adding to basket are unaffected.
Next update: by 14:30, or sooner if it changes.
Where to put the link
A status page nobody can find is a private apology. Put it in four places and it starts doing its job:
- Your site footer, on every page.
- The error page — the page a customer sees at the exact moment they need it.
- Your email signature, so it travels with you into inboxes.
- The first line of your support auto-reply during an incident, when volume spikes.
Frequently asked
Does a status page need to be public?
Yes for customer-facing sites: the whole point is that a worried visitor can check without logging in. Internal tools are the exception — those pages can sit behind a login with no loss.
Should I keep it up when everything is fine?
Keep the page live and green. A status page that only appears during an outage looks like a red flag with a URL; a page that is quietly operational all year is a trust signal.
How current does it need to be?
Automatically, within a minute of an outage starting, if the page is wired to your monitoring. Manually updated pages drift, and a page showing "operational" while the site is down does more damage than having no page at all.
Can I put it on my own domain?
On most paid plans, yes — a subdomain such as status.yourdomain.com. It takes one DNS record and it is worth doing, because customers trust an address that matches the site they were already on.
Wired to your monitoring, automatically
observer.to gives every monitor a hosted status page that updates itself the moment a check fails — green when you are up, amber when you are slow, red with a timestamp when you are down. Custom domain and white-label pages come with the paid tiers. Start a monitor and we will set the page up with you.