Eclips UK All articles
IT Procurement

Credits, Caveats and Continuity: A UK Procurement Review of Cloud Outage Terms

Eclips UK
Credits, Caveats and Continuity: A UK Procurement Review of Cloud Outage Terms

Photo: Dietmar Rabich, CC BY-SA 4.0, via Wikimedia Commons

When a cloud service fails, the first question from the business is usually practical: what can we still do? The first question in the contract is often narrower: what credit are we owed? Those two questions are not the same, and the gap between them is where procurement earns its keep. A service-level agreement can be perfectly clear about availability while saying very little about the operational consequences of an outage. For UK buyers, the task before renewal is to read the terms as a continuity document, not merely as a pricing schedule.

The uptime figure is a starting point, not a promise of continuity

A headline availability commitment of 99.9 per cent sounds robust until it is translated into time. It also invites a more important question: availability measured where, over what period, and by whom? A monthly measurement window can conceal a short but severe outage that falls just inside the tolerance. A measurement point deep inside the supplier's network may not reflect what the customer actually experiences. And an SLA that covers a platform but excludes a dependent service may leave the buyer with a credit for one component and no remedy for the business process that stopped.

Procurement should ask for the definition of unavailability, the measurement methodology, the reporting source and the customer's right to challenge the supplier's figures. Without those details, the percentage is a marketing number rather than an operational one.

How service credits work, and what they do not cover

Service credits are usually calculated as a percentage of the monthly or annual fee, triggered when availability falls below a threshold. The mechanics matter. Is the credit automatic or must the customer claim it within a fixed window? Is it applied to the next invoice or paid in cash? Is it capped at a modest proportion of the monthly fee? Does it apply to the whole service or only the affected component?

Even a generous credit regime rarely compensates for lost revenue, overtime, customer inconvenience or regulatory exposure. Most cloud contracts exclude indirect and consequential loss, and many cap liability well below the operational impact of a serious outage. That does not make the contract unreasonable by default, but it does mean the buyer should not treat credits as insurance. They are a discount on a failed month, not a funding source for recovery.

Exclusions that can hollow out the remedy

The most important clauses are often the ones that remove events from the SLA. Scheduled maintenance is a familiar exclusion, but buyers should look closely at how much notice is given and whether maintenance can be moved into peak hours. Emergency maintenance may be excluded with little warning. Force majeure clauses can be broad enough to capture supplier-side failures that the customer would regard as ordinary operational risk.

Other exclusions deserve equal attention: customer misconfiguration, unsupported integrations, beta or preview features, third-party dependencies and outages caused by the customer's own network. Some are legitimate. Some are so widely drawn that the SLA applies only to a narrow set of circumstances. The procurement question is not whether exclusions exist, but whether the remaining commitment still matches the service the business believes it is buying.

Notice periods and the operational fine print

A cloud outage is also a communications event. The contract should set out how quickly the supplier will notify the customer, where status information will be published, and what level of detail will follow. A status page that says "investigating" for several hours is not the same as an incident report that identifies scope and expected recovery.

Buyers should also check whether the supplier commits to recovery time objectives, recovery point objectives or any continuity standard. Many standard cloud terms do not. They promise availability, not restoration within a defined period, and they may not guarantee data retrieval times after termination. For UK organisations with regulatory obligations or critical customer services, those omissions matter more than a marginal difference between 99.9 and 99.95 per cent.

Model the outage, not just the credit

A useful renewal exercise is to estimate the cost of a working day without the service. Include staff time, lost transactions, manual workarounds, customer service pressure and any regulatory or contractual consequences. Then compare that figure with the maximum service credit available under the contract. In many cases the credit will be a small fraction of the loss. That is not necessarily a reason to reject the supplier, but it is a reason to plan continuity separately.

Procurement should also test the supplier's exit and data-return terms. If the service goes dark for an extended period, can the business retrieve its data in a usable format and within a defined time? Are there dependencies that would make migration impractical? A contract that is silent on exit is not neutral; it leaves the customer exposed at the point of greatest weakness.

A short contract-review checklist before renewal

None of this requires a legal qualification, but it does require a disciplined reading. The useful question is not whether the supplier offers a familiar uptime percentage. It is whether the contract gives the business enough time, information and practical remedy to recover when the service is unavailable. For UK buyers approaching renewal in 2026, that distinction should sit at the centre of the procurement conversation.

All Articles

Related Articles

The Fibre You Inherit: A UK Connectivity Checklist for Office Moves

The Fibre You Inherit: A UK Connectivity Checklist for Office Moves

The Disposal Gap: Why Windows 10 Retirement Is a Procurement Test, Not an IT Task

The Disposal Gap: Why Windows 10 Retirement Is a Procurement Test, Not an IT Task

The Settings You Did Not Choose: A UK Review of Inherited Cloud Configurations

The Settings You Did Not Choose: A UK Review of Inherited Cloud Configurations