A status page started as a courtesy. Something was broken, engineers wanted customers to stop filing tickets, and a public page saying so was cheaper than answering the phone. The tone was informal because the audience was assumed to be sympathetic.
The audience is no longer only engineers. It is procurement teams computing service credits, lawyers establishing whether a remedy was triggered, and auditors reconstructing a timeline. What gets typed at three in the morning is now the record.
Availability is defined by whoever writes the update
Most agreements express uptime as a percentage over a month, which sounds objective and is not. The number depends entirely on what counts as downtime, and that is established by the vendor's own incident timeline — the moment it declares an incident began, the moment it declares recovery, and whether the event is classed as degradation rather than an outage.
Every one of those is a judgement made under pressure by someone whose employer pays credits on the answer. It is not usually dishonest. It is simply that a vendor grading its own homework will grade generously at the margin, and the margin is where the credits live.
Sophisticated buyers have started to notice. Contracts increasingly specify who declares an incident, require notification within a fixed period rather than at the vendor's discretion, and define degradation explicitly rather than leaving it as a category the vendor can move things into. That is the same maturing visible where corporate buyers pushed for standard terms in model contracts — the technology got serious, so the paperwork did.
There is a reputational calculation running against the legal one, and it points the other way. The vendors people trust are the ones that publish detailed post-incident reviews naming the actual cause, which is precisely the document a plaintiff would most like to have. Legal counsel would prefer vaguer language; engineering leadership knows vagueness is read as evasion. Where the lawyers win that argument, customers notice, and the status page becomes a place where nothing ever quite goes wrong.
For a company running dozens of vendors, the practical problem is aggregation. A business that owns more software than it can account for has no single view of whether its own service was degraded by someone else's incident, and reconstructing that after the fact means reading a dozen status histories written to a dozen different standards. Insurers are beginning to ask for exactly this reconstruction, which is how cyber underwriting became the de facto regulator of everything adjacent to it.
Topics technologysaascontracts
