The Amber Dashboard: Auditing UK Status Pages When Nothing Is Fully Down

A status page can be entirely green while a customer is entirely stuck. The binary vocabulary of operational, degraded and major outage rarely matches the lived experience of a UK user trying to pay a council tax bill, book a GP appointment or renew a rail season ticket when one dependency is slow, one channel is failing and the rest of the estate is fine. Partial outages are not edge cases. They are the normal shape of modern service failure, and they are where status pages most often mislead.

Green is not a diagnosis

Many status pages were designed for clean, total outages. They answer whether a platform is up, not whether a person can complete a task. A payment provider may be accepting most transactions while one bank's cards fail. An identity service may be slow only for users with older devices. A mobile app may be unable to refresh while the web journey works. In each case, the status page can truthfully say that the service is available and still leave the customer without the information they need.

At Usability247, we treat the status page as part of the journey, not a public relations appendix. The audit question is not whether the page is accurate in engineering terms. It is whether a worried customer can use it to decide what to do next.

The three questions

Every status page should let a customer answer three questions in under a minute, ideally without reading an incident essay.

First, am I affected? This requires impact scope, not just a service name. Which channel, region, customer group or transaction type is affected? Is the problem intermittent or constant? Is it slowing people down or stopping them? A phrase such as some users may experience issues is technically safe and practically useless. Better: card payments are failing for customers using one bank's cards; other payment methods are working.

Second, what should I do now? The page should give a clear action: retry, use another channel, wait, avoid submitting the same payment twice, contact support only if a specific condition applies. Where there is no safe workaround, say so plainly. Customers can tolerate bad news. They struggle with ambiguity.

Third, when will this change? This is not a demand for a precise fix time. It is a demand for a credible update rhythm. A stale timestamp is worse than no timestamp because it implies someone is watching. State the last update, the next expected update and the time zone. In the UK, that means being explicit about GMT or BST, especially around the clocks change. A page that says next update at 14:00 without a time zone is only half a promise.

A repeatable scoring method

We use a six-part rubric for partial-outage status pages. Each criterion is scored 0, 1 or 2, giving a maximum of 12. The audit should be run against at least three realistic partial-failure scenarios, not a single major outage. Recruit participants who resemble the affected customer group, and ask them to think aloud while answering the three questions.

Criterion	0	1	2
Impact clarity	No scope beyond service name	Some scope but vague	Channel, group and effect are explicit
Action guidance	None	Generic advice	Specific, safe next step
Temporal certainty	No update time	Last updated only	Last and next update with time zone
Live update accessibility	Auto-refresh, visual only	Partial support	Announced, readable, controllable
Incident history	Missing or unreadable	Present but buried	Searchable, dated, plain-language
Freshness and ownership	Stale or anonymous	Updated but owner unclear	Current, owned, cadence stated

A score of 10 to 12 suggests the page is fit for partial-outage use. Seven to nine means it needs targeted remediation. Six or below means the page is likely to increase support demand and erode trust. Record evidence for every score: a screenshot, a timestamp, a participant quote, the point at which they gave up.

Freshness and the incident record

Partial outages often produce long, low-drama incidents. The status page may be updated once, then left while engineers investigate. That is where stale timestamps do damage. If the last update was at 09:12 and it is now 11:40, the customer has no reason to believe the page is live. A relative timestamp such as 12 minutes ago is helpful only if it is accurate and if the absolute time is also shown.

Incident histories deserve the same rigour. They should be dated, written in plain English and structured so that a customer can find the partial incident that matches their symptom. Avoid resolved labels that mean monitoring rather than fixed. Avoid closing an incident while a workaround is still in force. The history is not an archive for engineers. It is a trust record for customers and, in regulated sectors, for complaints and redress.

Live updates that some customers cannot perceive

Status pages frequently rely on colour, animation and automatic refresh. A green badge, an amber banner and a spinning icon are not accessible status communication on their own. Use text labels, ensure contrast meets WCAG 2.2 AA, and do not move focus when an update arrives. If the page uses live regions, choose polite announcements for routine updates and reserve assertive announcements for genuine safety or payment risks.

Test the page with a screen reader, at 200 per cent zoom and on a slow mobile connection. Check that the incident timeline is an ordered list with headings, not a canvas or an endlessly loading feed. Provide a static fallback and an email or SMS subscription for people who cannot keep a browser open. Public sector bodies in the UK have additional accessibility obligations; private organisations still have duties under the Equality Act 2010. Accessibility is not a separate audit from usability here. It is the same question asked of a different user.

Make the page part of incident response

The most common cause of a poor status page is not bad design. It is bad process. No one owns the copy, no one has authority to publish an impact statement, and no one has rehearsed the page under pressure. Assign a status-page owner in the incident team. Prepare templates for partial degradation, dependency failure and channel-specific failure. Run a quarterly drill with a realistic scenario and score the page using the rubric above.

A simple impact statement can carry most of the load: We are aware that the service or channel is slow, intermittent or unavailable for a group or region. You can still use the safe workaround. We will update by the stated time and time zone. That sentence does not pretend certainty. It gives the customer a bearing.

All systems green is a monitoring outcome, not a customer outcome. A status page earns its place when it helps someone decide what to do while the system is only partly working. Audit it for that moment, and the page becomes more than a dashboard.