Cloud SLA negotiation: what enterprise buyers must demand.

01 Key findings

1. Uptime percentages are widely misread. 99.9% permits 8.7 hours of downtime per year (43 minutes per month); 99.99% permits 52 minutes per year; 99.999% permits 5.2 minutes. The gap between tiers is commercially material and worth explicit negotiation for critical workloads.

2. Standard credits are not remedies. Credits of 10–30% of monthly fees bear no relationship to business loss. Mission-critical workloads need graduated credits — 50%, 75% or 100% for extended outages — plus remedies beyond credits.

3. Exclusions are where the risk lives. Planned maintenance, DNS failures, force majeure and the broad “customer error” carve-out routinely void coverage. The maintenance exclusion is the most damaging: providers may patch during your peak hours with no recourse.

4. Dependencies compound. Five services each at 99.9% combine to roughly 99.5% (0.999⁵). Most large applications run below the availability the buyer believes it purchased.

5. Monthly measurement creates perverse incentives. Because credits trigger on cumulative monthly thresholds, providers optimise to keep any single incident just short of the trigger rather than to prevent recurrence. Shift measurement to incident-duration thresholds.

02 What SLAs really guarantee

A cloud SLA specifies an uptime percentage, what happens if it is missed (typically service credits), and the events excluded from the guarantee. Crucially, it is defined in terms of infrastructure uptime, not business outcome. “99.9% uptime” does not mean your application is available 99.9% of the time — it means the provider’s compute, storage and networking components meet a technical benchmark 99.9% of the time. Those are not the same thing.

Standard SLAs ignore application-level availability, third-party dependencies and your own configuration. Misconfigure a security group and block inbound traffic, and the provider is still meeting its SLA. Deploy a single point of failure across zones, and the SLA remains satisfied. Most enterprise incidents stem from architecture, configuration or excluded dependencies — not from provider infrastructure failure. Understanding this asymmetry is the foundation of intelligent SLA negotiation.

03 SLA terms to demand

Beyond the headline uptime figure, five terms decide whether an SLA actually protects the business. Demand each explicitly, and specify the standard rather than accepting the provider default.

04 The toothless-credit trap

Standard credits range from 10% to 30% of monthly service fees for the affected service. If a service costing $100,000 a month is unavailable for four hours — breaching the 99.9% SLA — the buyer receives $10,000–30,000 in credits. That is almost never equivalent to the loss. The structure of the calculation matters as much as the percentage: standard SLAs award flat credits by availability band, so a five-minute outage and a one-hour outage can return the same amount.

05 Dangerous exclusions

Exclusions are where the real risk sits. Standard SLAs exclude planned maintenance, DNS failures, force majeure, external attacks, third-party service failures, and anything attributable to “customer” actions. Two exclusions do the most damage.

The planned-maintenance exclusion lets providers patch, roll updates and move capacity — continuously — entirely outside the guarantee. If maintenance lands during your peak hours, you have no recourse, and the SLA often does not even define what “maintenance” means. Demand: maintenance only outside declared business hours, at least 14 days’ notice, no more than one window per service per month during business hours, and customer approval of proposed windows.

The “user error” carve-out excludes issues from “customer configuration,” “customer application code” or “customer API usage” — language broad enough to exclude almost anything not caused by a provider code bug. If unclear documentation leads you to misconfigure, is that user error or provider error? Narrow the exclusion to apply only to customer application code and data, not to platform configuration the provider should document clearly.

06 How uptime is measured

Measurement mechanics quietly decide who pays. 99.9% uptime does not mean the service is down for 8.7 hours spread randomly — it means cumulative unavailability stays under the monthly threshold. Eight consecutive hours down in one month breaches it and triggers credits; 43 minutes down does not. Multi-region deployments compound the problem: most SLAs apply per region, so a failover target without negotiated terms carries no guarantee at all.

07 Negotiation checklist

Work these factors before signing. Weight them to workload criticality, and raise enhanced-SLA requirements at the start of negotiations — not as an afterthought.

08 Our recommendation

09 Frequently asked questions

1. What does 99.9% uptime actually mean in terms of downtime? 99.9% uptime permits 8.7 hours of downtime per year, 43 minutes per month, or approximately 8.6 seconds per day. 99.99% permits 52 minutes per year; 99.999% permits just 5.2 minutes. Many buyers mistakenly read 99.9% as near-perfect, but it permits over 8 hours of unplanned downtime annually — and for mission-critical systems the gap to 99.99% is worth negotiating explicitly.

2. Are SLA credits the same as actual financial remedies? No. Standard credits are typically 10–30% of monthly service fees, almost never equivalent to the business loss. A firm losing trading systems for an hour may lose millions while credits total $5,000–10,000. Negotiate higher percentages (50–100% for extended outages), remedies beyond credits, and termination rights if uptime falls below threshold for consecutive months.

3. What are the most dangerous SLA exclusions? Planned maintenance (often excluded entirely, even during business hours), DNS failures and route issues, user error and misconfiguration, force majeure and external attacks, and third-party dependencies. Multi-tier architectures often breach thresholds because of excluded dependencies rather than provider failure. Demand exclusion of only truly uncontrollable events, prior notice of out-of-hours maintenance, and coverage or explicit acknowledgment for dependent services.

4. Can we negotiate higher SLAs for strategic cloud workloads? Yes. AWS offers enhanced SLAs up to 99.99% for specific services; Azure offers Premium SLAs above standard tiers; Google Cloud offers custom SLAs for large accounts. Enhancement typically requires a multi-year commitment, architect-level validation of criticality, willingness to implement recommended resilience patterns, and a credible threat to move workloads — most accessible at major renewals.

5. Who should help me negotiate cloud SLAs? The work spans architecture, commercial terms and risk. Internal teams should include infrastructure leads, finance, procurement and legal counsel. Externally, Atonement Licensing advises exclusively on the buyer side, with former AWS and Azure commercial team members. Avoid advisors holding provider certifications or reseller relationships, which create conflicts of interest.