Reading the Silence: How UK Buyers Should Score SaaS Vendors on Incident Disclosure

A green status page is a claim, not a measurement. It reflects what a vendor believes, or chooses to publish, about its own service at a given moment. When the page stays green while users across three UK offices cannot log in, the failure is not only technical. It is a failure of communication, and communication is the part of resilience that procurement can actually evaluate before signing.

Outages are ordinary. Silence during an outage is a choice, and it is a choice buyers can price.

What a status page is designed to do

Status pages were built as a deflection tool. They reduce inbound support tickets during a known incident, which is a reasonable aim. They are not audit instruments. Definitions vary between vendors: a partial outage from one supplier may describe the same event that another calls degraded performance, and maintenance windows are frequently used to absorb unplanned work after the fact. None of this is necessarily dishonest, but it means the page should be treated as a live indicator rather than a record.

Buyers who want a record should build one. Independent synthetic checks from your own estate, or a third-party monitoring service that tests the specific functions your staff use, produce evidence the vendor cannot edit. Two probes — one from the office network, one from a cloud region — cost little and settle arguments quickly.

The postmortem test

Ask for the last three postmortems the vendor published, not the one they wrote for the sales process. A credible write-up contains five things:

1. A timeline in timestamps, aligned to a stated time zone, from first signal to full restoration.
2. A plain description of customer impact, including which functions and which regions were affected.
3. Root cause at a level of detail that would allow a competent engineer to understand the failure mode.
4. Remediation actions with owners and dates, and evidence that earlier actions were closed.
5. A statement of what the vendor did not know, and when they knew it.

The fifth point is the discriminating one. Vendors that admit the limits of their early information tend to communicate better in the moment; vendors whose postmortems are uniformly flawless usually have a communications problem that has not yet surfaced.

Contract notices that do something

Most SaaS agreements contain notification obligations, but many are drafted so loosely that they cannot be enforced. Four clauses are worth attention at renewal.

Incident notification. Look for a defined trigger, a named channel and a stated window. A commitment to notify affected customers within sixty minutes of confirming a severity-one incident, by email to a named contact as well as the status page, is testable. A commitment to keep customers informed is not.

Update cadence. Specify a minimum frequency during an active incident — every sixty minutes, for example — and require a final summary within five working days.

Root cause reporting. Require a written root cause analysis on request for any incident exceeding an agreed duration, with a right to discuss remediation on a call.

Data events. Where personal data may be involved, the vendor's obligations as a processor sit alongside UK GDPR requirements. The controller's own seventy-two-hour window to the Information Commissioner's Office starts when it becomes aware, so contractual notification to you must be materially faster than that. Anything vaguer than twenty-four hours leaves you unable to meet your own duties.

SLA credits deserve a mention mainly to set expectations. They are typically calculated against monthly fees, capped, and available only on request. They are a refund of charges, not compensation for business interruption, and they should not be presented internally as a resilience control.

Rehearse the route while it is quiet

An escalation path that has never been used is a diagram. Once a year, take the vendor's named contacts, the out-of-hours number and the account manager's mobile, and test them with a non-urgent question outside normal hours. Record how long a human takes to respond. Ask who has authority to declare a severity-one incident, who writes customer communications, and whether the person on the support desk can reach them at two in the morning.

Run a short tabletop exercise with your own team as well. Who decides whether to invoke a manual workaround? Who tells customers? Who owns the internal update at ten o'clock? Firms that answer these questions in advance recover composure far faster than those improvising in a group chat.

A transparency scorecard

Score each candidate or incumbent out of one hundred, and take the result to the renewal meeting alongside price.

A vendor that scores well on uptime marketing and poorly here is telling you something specific: the service is reliable until it is not, and you will learn about it last. That is a commercial risk, and it belongs in the negotiation rather than the appendix.

The conversation at renewal

Transparency commitments are cheap for a good vendor to give and awkward for a poor one to accept. Ask for the notification clause, the cadence commitment and the root cause obligation as amendments, and treat resistance as information. Where the contract is already signed, ask for the last three postmortems and a walkthrough of the escalation route; the quality of the answer is a fair proxy for the quality of the next incident.

Resilience is partly a communication product. Buyers who evaluate it like one tend to spend far less of the next outage explaining to their own board why nobody called.