Contents
On 18 November 2025, a Cloudflare outage disrupted a large number of websites and online services for roughly six hours. For some organisations, the impact was limited to inconvenience or reputational discomfort. For others , particularly e-commerce platforms and digital services whose revenue generation depends directly on availability, the consequences were immediate and measurable: failed transactions and real, lost revenue.
What struck me at the time was not only the scale of the outage, but its breadth. It affected small companies and large enterprises alike, including organisations that contract with Cloudflare precisely because it is considered critical, enterprise-grade infrastructure.
Having worked extensively with enterprise SaaS and cloud infrastructure agreements, I had a strong intuition as to how this would play out contractually. In most such agreements, service credits are effectively the best outcome a customer can hope for. Still, I wanted to test that intuition against the actual enterprise terms.
So I went back to the source: Cloudflare’s Enterprise Service Level Agreement, the warranty provisions, the termination mechanics, and the limitation of liability clauses. What emerged was not an aggressive outlier, but a familiar risk allocation model which, even in the face of systemic outages, the economic consequences are very often borne by customers themselves.
I. What the Enterprise SLA actually provides
Let us apply this to a realistic enterprise scenario, using Cloudflare’s own SLA mechanics. Cloudflare’s Enterprise SLA promises 100% uptime, with service credits as the sole and exclusive remedy for service level failures.
Section 10.1 of the SLA defines the service credit calculation as follows:
Service Credit = (Multiplier x Outage Period minutes × Affected Customer Ratio x Monthly Fee) ÷ Scheduled Availability minutes
For the purposes of this analysis, we apply conservative and explicit assumptions for a mid to a big size company:
- Outage duration: 6 hours (360 minutes)
- Month length: 30 days (43,200 scheduled availability minutes)
- Affected Customer Ratio: 1.0 (full impact)
- Monthly Cloudflare fees: $25,000
- Support tier: Premium, applying the Premium service credit multiplier
The base fraction under Section 10.1 is: 360 ÷ 43,200 = 0.833%. Under the Premium plan, this base percentage is multiplied by the applicable Premium multiplier, resulting in a credit of approximately 20.83% of the monthly fee. Applied to monthly fees of $25,000, the service credit owed is therefore approximately: $5,200. This amount falls well below the SLA’s annual credit cap and therefore applies in full.
Now, let’s compare the contractual remedy to real business loss. Assume that the affected service is revenue-generating — for example, an e-commerce platform, subscription service, or transactional application — and that the outage results in lost revenue and operational disruption of approximately $100,000 per hour. Over a six-hour outage, the total loss is therefore: $600,000
Against that figure, the contractual remedy of $5,200 covers less than 1% of the actual loss.
Even under:
- a 100% uptime SLA,
- Premium enterprise support,
- full customer impact, and
- perfect eligibility for credits,
the gap between operational dependency and contractual protection remains substantial.
II. How enterprise SaaS contracts allocate outage risk
To understand why this outcome is so consistent, it helps to look at the contractual architecture as a whole rather than at individual clauses in isolation.
1. SLAs: containment, not compensation
In enterprise SaaS contracts, SLAs are often perceived as the primary protection against downtime. In practice, they serve a different function.
Availability failures are channelled into the SLA and addressed through predefined service credits, which are expressly framed as the sole and exclusive remedy for service level failures. The calculation is mechanical, capped, and detached from the customer’s actual business impact. The SLA does not aim to compensate loss. It converts downtime into a pre-priced adjustment to the service fee. For minor incidents, this may feel reasonable. For large-scale outages, the disconnect becomes unavoidable.
2. Warranties: deliberately not about availability
Enterprise customers sometimes assume that warranties provide a second line of defence. In most SaaS contracts, they do not. Warranties typically focus on conformity with documentation and adherence to security standards, while explicitly excluding service level failures from their scope. The result is that even repeated or severe outages cannot be reframed as warranty breaches.
3. Termination: a safeguard that rarely triggers
Termination rights usually require a material breach that remains uncured. Because SLA failures are carved out of the warranty regime and dealt with exclusively under the SLA, they do not naturally accumulate into a material breach. There is often no contractual concept of chronic unreliability, no mechanism by which repeated outages become “enough” to satisfy the criteria for a breach of the SLA to become material.
4. Limitation of liability: the final lock
Finally, limitation of liability clauses exclude precisely the types of loss that outages cause: lost revenue, lost business, loss of goodwill, and indirect or consequential damages.
Taken together, these elements form a coherent liability stack:
- the SLA limits remedies to credits only;
- the warranty excludes outages;
- termination does not scale with repetition; and
- limitation of liability removes meaningful economic recovery.
III. Where enterprises can actually get leverage
Enterprises rarely succeed in negotiating damages in place of service credits with big cloud and SaaS providers. That battle is usually lost before it starts. Where negotiation is possiblem it tends to focus not on increasing financial liability, but on reshaping how failure is handled: through escalation rights, termination triggetrs and exit mechanics.
1. Escalation triggers, not higher credits
Service credits are rarely valuable as compensation, but they can be valuable as formal triggers. When SLA failures are linked to escalation mechanisms, for example, enhanced support levels, management escalation, or contractual review triggers — they stop being symbolic. They become measurable events that activate consequences elsewhere in the relationship.
2. Termination rights linked to service level performance
One of the most realistic and meaningful negotiation points is termination for persistant failure to meet service levels. Rather than trying to monetise outages, customers are often better served by securing an early exit where availability commitments are missed repeatedly over a pre-defined period. This does not punish isolated incidents, but it protects against systemic unreliability.
3. Exit assistance
Termination without an exit path is rarely useful. Exit assistance, continued access for a transition period, data export support, and reasonable cooperation, is often far more valuable than incremental SLA credits when things go wrong.
IV. Risk mitigation beyond the contract
Even well-drafted contracts will not close the gap between operational dependency and contractual protection.
For revenue-critical services, enterprises increasingly rely on design and governance, not legal remedies.
This may include multi-cloud or hybrid architectures, on-premise fallbacks for critical functions, or container-based portability (for example, through Kubernetes). These approaches are expensive, complex, and operationally demanding, and that cost is precisely why they should be reserved for truly critical dependencies.
Insurance can transfer part of the financial risk, but coverage for third-party cloud outages remains limited, expensive, and highly conditional. It is a complement, not a solution.
The uncomfortable reality is that contractual remedies are typically the last line of defence, not the first.
V. A short checklist for decision-makers
For any service that sits in the revenue-critical category, the following questions are often more important than the SLA percentage:
- What happens if this service is unavailable for six hours?
- Can we still take orders, authenticate users, or process payments?
- Do we have a fallback, bypass, or alternative path?
- Can we quantify the loss and trigger internal escalation?
- Can we exit within a reasonable timeframe if reliability deteriorates?
If the answer to most of these is “no”, the economic and operational risk has not moved to the provider. It remains with the business, even though it is now framed contractually as an SLA issue rather than a continuity or revenue risk.
Takeaway
When the cloud goes down, contracts rarely determine who bears the economic risk. Architecture, governance, and exit options do.
Enterprise SaaS agreements are not broken. They do exactly what they are designed to do: provide predictable, capped exposure for vendors. The mistake is assuming that they also protect customers against the business consequences of correlated outages.