Green Lights and Blind Spots: What Vendor Status Pages Don't Tell UK Teams

Every SaaS product has a status page. It usually lives behind a link in the footer, next to the privacy policy and the terms nobody reads. And it usually has a green dot. The green dot is comforting. It is also a mood, not a measurement. A status page is a communication product maintained by the vendor — often by support or marketing — not a raw feed from their monitoring stack. For small UK teams without a network operations centre, learning to read one properly is a cheap way to avoid nasty surprises.

Start with the timeline, not the colour

Colour is a summary. The timeline is evidence. When something goes wrong, look at the timestamps. When was the incident opened? When was it updated? When was it resolved? The gap between ‘investigating’ and ‘identified’ often tells you more about the vendor’s operational maturity than the final resolution note. A page that says ‘investigating’ for six hours and then ‘resolved’ is not giving you a diagnosis. It is giving you a press release with timestamps.

Operators read the sequence. Customers read the colour. If you want to know what happened, read the sequence.

Detection time is the number that matters

Vendors love to quote resolution times. ‘Resolved in 45 minutes’ sounds efficient. But if detection took 40 of those minutes, the real impact was longer. The useful comparison is detection time versus resolution time. When did the vendor know? When did your users know? Those two moments are rarely the same.

Imagine a Tuesday morning. Your finance team cannot log in at 09:10. The status page stays green until 09:50, then turns yellow and says ‘We are aware of an issue affecting some users’. That 40-minute gap is your real exposure. It is also the gap that never appears in a service review unless you write it down.

If detection times are consistently long, treat that as a risk. It is not necessarily a reason to leave, but it is a reason to ask questions at renewal. A vendor that notices its own outages quickly is easier to work with than one that relies on customers to tell it.

The pruning problem

Historical incidents are a resource. Some vendors keep a rolling window — 30 days, 90 days — and quietly prune the rest. That can be perfectly reasonable for a public page, but it means you are not looking at a history. You are looking at a highlight reel.

Check whether you can see incidents from six months ago. If you cannot, ask why. Is it a policy? A platform limitation? Or is the page simply optimised for reassurance? None of these are automatically sinister, but they change how much weight you should give the page during procurement or renewal.

This is where your own records start to matter. A simple shared document is enough: date, time you noticed, service affected, symptom, what the status page said at that moment, when it next updated, when service returned, and whether you received a proactive notification. That log becomes evidence when someone claims ‘we have never had an outage like that’. It also stops you relying on memory, which is notoriously bad at remembering exactly when a Thursday afternoon went sideways.

‘Degraded performance’ is a container, not a diagnosis

Phrases like ‘degraded performance’ and ‘intermittent issues’ are elastic. They can describe a minor slowdown affecting one feature in one region. They can also describe a partial outage where half your team cannot log in while the status page stays yellow. Yellow is a broad church. For the vendor, yellow is better than red. For you, yellow may be the difference between a normal day and an incident bridge.

Read the updates carefully. If the page says ‘some users may experience…’, ask which users, which regions, which features. If the page does not say, your own tests do. Try logging in from a different network. Ask a colleague in another office. Check the specific feature your team depends on, not just the homepage. The status page is a starting point, not a diagnosis.

Maintenance windows are part of the record

Scheduled maintenance is often posted as a courtesy, then quietly extended. Check whether windows are honoured. A ‘minor’ maintenance window that turns into a two-hour outage during your busiest period belongs in your vendor notes. UK teams should also watch time zones. A window advertised in UTC can land in the middle of a working day, and a Friday evening window can bleed into a bank holiday weekend.

This is not about catching vendors out. It is about understanding the difference between planned work and unplanned impact. Both affect your team. Only one tends to appear prominently on the status page.

Build a shadow log before you need it

You do not need a tool. A spreadsheet is fine. The habit matters more than the format. Log the basics: what you saw, when you saw it, what the vendor said, and when the vendor said it. Take a screenshot of the status page at the time. Pages change. The version you see next week may not match the one you saw during the incident.

This is not about mistrust. It is about having a factual record for service reviews and renewals. If a vendor asks for feedback, you can give specific examples. If a procurement conversation turns to reliability, you can talk about detection times rather than vibes. And if a service credit is disputed, your log is more useful than a green dot.

Questions to take to renewal

At the next renewal, ask for detection time, resolution time and notification time for the last few incidents. Ask whether they publish post-incident reviews. Ask if historical incidents are pruned. Ask how they decide between yellow and red. None of this needs to be adversarial. It is procurement hygiene, and most vendors will answer.

If they cannot answer, your shadow log can fill the gap. That is the quiet advantage of keeping your own record: you are not dependent on the vendor’s memory or their dashboard design choices.

The green dot is a starting point

A status page is useful. It is just not authoritative. The operator’s habit is simple: read the timeline, check the history, log your own. Do that, and the next incident will still be annoying — but it will not be a mystery. And when the review comes around, your evidence will still be there even if the vendor’s page has moved on.