Degraded, Disrupted, Down: How to Read a Cloud Status Page Without Taking It at Face Value

There is a particular kind of frustration that only arrives at 9:40 on a Monday morning. Your team is fielding calls because the ordering system is dead. You check the provider's status page. It reads: degraded performance in EU-West region. Engineers are investigating.

Degraded. Your customers would use a different word.

This is not really an article about outages. It is an article about language, and about the gap between what a provider tells you and what is actually happening to your business.

Why status pages lean vague

A status page is not purely an operations tool, whatever the design suggests. It sits at the intersection of engineering, legal and marketing, and all three have an interest in the wording.

Engineering may not know the full picture yet. Legal prefers nothing that reads like an admission. Marketing does not want a public page that looks like a Disaster headline every quarter. The result is a vocabulary of soft edges, where "degraded" might mean a tenth of a second of extra latency or might mean a region has fallen over and nobody has said so yet.

Add to that the fact that the person posting updates is often a duty engineer relaying messages, not the person who understands the root cause. Honest ambiguity and defensive ambiguity look identical from the outside.

A short glossary of euphemism

You will see these phrases repeatedly. Here is a rough translation.

• Degraded performance. Something is broken. We are not yet saying what, or how badly.
• Investigating. We have noticed. We do not know why. Do not expect a timeline.
• Mitigating. We have turned something off or routed around it. The underlying fault is still there.
• Service restored. Error rates are back to normal. Your backlog, queues and half-finished transactions may not be.
• Scheduled maintenance. We are changing something and hoping it goes smoothly.
• A small number of customers may be affected. We have not worked out how many, or we have and it is not small.

None of this is necessarily dishonest. But it is written for the provider's comfort, not yours.

What good incident communication looks like

It is worth knowing the standard, because it makes the shortfall obvious. A provider doing this well will typically:

• Name an incident commander and say updates will come every 30 minutes, even when there is nothing new. Silence is worse than bad news.
• State impact in customer terms: "new orders are failing in the London region", not "elevated error rates observed".
• Say which services and which locations are affected, using names customers recognise rather than internal codes.
• Offer a workaround if one exists, and say plainly if one does not.
• Commit to publishing a post-incident review within a set number of days, and then publish it.

The 30-minute cadence is the tell. Providers who update on a schedule have built a process. Providers who update when they feel like it have built a habit.

SLA credits are not compensation

Here is the bit that surprises a lot of UK finance and ops teams. A service level agreement is a contractual promise about a measured metric, usually availability, calculated the provider's way. It is not a promise that your business will keep working.

Things to check in your own contract:

• The definition of downtime. Does a partially failed service count? Does a failure in one availability zone count if another stayed up?
• Where it is measured. From the provider's edge, or from the customer's experience?
• The credit size. Often a percentage of the monthly fee for that service, scaled by how far below target it fell. A 99.9% monthly target still permits roughly 43 minutes of downtime, and many teams have no idea that is the baseline they signed up to.
• The claim process. Plenty of agreements require you to request credits within a window, with evidence. Nobody sends them automatically.
• Exclusions. Force majeure, customer misconfiguration, beta features, and sometimes "scheduled maintenance" all sit outside the promise.

Compare that with the real impact: orders lost, staff sitting idle, contractual penalties you owe your own customers, and the marketing spend you will need to win back trust. Credits rarely come close. They are a gesture written into a contract, not an insurance policy.

Questions worth asking after the next outage

This is where most teams leave value on the table. Once service is back, ask for specifics in writing. A decent provider will answer. A weak one will send a link to the status page.

1. Give us the timeline in UK time, from first customer impact to full recovery.
2. What did our monitoring see, and when did yours first detect it?
3. How many of our resources were affected, and for how long each?
4. Was failover automatic? If not, why not?
5. What changed in the 24 hours before the incident?
6. When will the backlog be fully cleared, not just the error rate?
7. When will the post-incident review be published, and will it be public?
8. What specifically has changed to stop a repeat?
9. How is our credit calculated, and what do we need to submit to claim it?

Question six catches people out. An outage that ends at 11am can leave queues draining until mid-afternoon, and nobody credits you for the queue.

Keep your own receipts

Your strongest position at renewal is your own evidence. Log outages yourself, with timestamps, from a location that reflects your users. Screenshot the status page while it still says "investigating". Note the moment your support queue spiked. Capture customer complaints, not in detail, just in volume.

That record turns a vague conversation about reliability into a specific one. It also means that when a provider claims a 99.98% quarter, you can compare it against what your staff actually experienced, which is the only number your board cares about.

Reassurance versus evidence

Status pages are written to reassure. That is fine, as long as you read them as reassurance rather than evidence, and go looking for the evidence yourself.

The team that asks the nine questions above, keeps its own downtime log and knows what its SLA actually says will always get a straighter answer than the team that refreshes the status page and hopes. That is not cynicism. It is just reading between the lines.