Cloud service level agreements (SLAs) are contracts between a cloud provider and a customer that set a minimum availability target, usually expressed as a monthly uptime percentage like 99.9%, and define the financial credit you can claim if the service falls short. Rather than promising that an outage will never happen, uptime guarantees specify how the provider measures downtime, which deployment configurations qualify for coverage, and what percentage of your monthly bill gets credited toward future invoices after a verified breach.
According to Microsoft Learn’s SLA documentation updated in April 2026, an SLA is an engineering signal and a financial commitment rather than a guarantee of uninterrupted service. Even a platform that meets every line of its contract can experience brief disruptions or require you to build redundancy across multiple data centers before any compensation applies.
How do SLIs, SLOs, and cloud service level agreements differ?
Reliability engineering separates day-to-day performance tracking from legal contracts using three distinct terms formalized in Google’s 2016 Site Reliability Engineering book and detailed in ClickHouse’s 2026 engineering breakdown and Microsoft Learn’s 2025 reliability documentation.
- A Service Level Indicator (SLI) is the raw quantitative measurement of how a system behaves over a specific time window, calculated by dividing good events by total valid events (ClickHouse, 2026; Microsoft Learn, 2025). Depending on the service, that metric might track the share of HTTP requests that return a successful status code or the minutes a virtual machine can reach the network.
- A Service Level Objective (SLO) is the percentage target an engineering team sets for an indicator over a rolling or monthly window, such as keeping successful responses at or above 99.9% over 30 days (ClickHouse, 2026). The remaining percentage, calculated as 1 minus the SLO, is the error budget: the maximum downtime or failure rate the system can absorb before breaching its goal (ClickHouse, 2026).
- A Service Level Agreement (SLA) is the external contract with customers that attaches financial consequences, almost always future billing credits, to meeting specific objectives (Microsoft Learn, 2026; ClickHouse, 2026).
As Google Cloud’s reliability engineering guidance (2021) explains, providers typically set their internal objectives stricter than their public SLA thresholds. Tighter internal targets give engineering teams an early warning buffer to halt risky code releases or fix degraded hardware before customer-facing downtime triggers contractual penalties, while recognizing that chasing 100% reliability slows feature development and raises operating costs (Google Cloud Blog, 2021).
How much downtime do uptime guarantees allow each month?
Cloud providers group uptime guarantees by the number of “nines” in the monthly percentage, and each additional nine cuts the permitted downtime tenfold (Uptime.com, 2024; ClickHouse, 2026). Over a standard 30-day observation window, ClickHouse’s 2026 engineering calculations show how much cumulative downtime a provider can experience without breaching its target:
- 99% (“two nines”) allows up to 7.2 hours of downtime per 30 days (ClickHouse, 2026).
- 99.5% allows up to 3.6 hours of downtime per 30 days (ClickHouse, 2026).
- 99.9% (“three nines”) allows up to 43.2 minutes of downtime per 30 days, or roughly 43 minutes and 12 seconds per month (ClickHouse, 2026; Uptime.com, 2024).
- 99.99% (“four nines”) allows up to 4.3 minutes of downtime per 30 days (ClickHouse, 2026).
- 99.999% (“five nines”) allows up to 26 seconds of downtime per 30 days (ClickHouse, 2026).
Because the threshold is measured across an entire monthly billing cycle, a service with a 99.9% monthly target can suffer a complete 40-minute outage during peak business hours and still fulfill its contract with three minutes to spare (Microsoft Learn, 2026; ClickHouse, 2026).
How do cloud providers calculate monthly uptime percentages?
Most infrastructure providers use either a time-based formula or a request-based formula to calculate whether an outage crossed the monthly threshold. In its April 2026 guide “How to Read a Service-Level Agreement (SLA)”, Microsoft Learn gives the standard time-based equation used across cloud platforms:
Monthly Uptime Percentage = ((Total Billable Minutes – Downtime) / Total Billable Minutes) x 100
Time-based SLAs apply to continuously running resources such as virtual machines or dedicated gateways, counting the minutes a resource is unreachable (Microsoft Learn, 2026). Request-based SLAs apply to APIs, serverless functions, and managed databases, dividing successful responses by total valid requests within fixed intervals (Microsoft Learn, 2026).
The fine print in those interval rules changes what counts as downtime. Under the October 2026 AWS Continuum Service Level Agreement, availability is evaluated in 5-minute intervals where errors are defined as requests that return HTTP 500 or 503 status codes, and any 5-minute interval in which you make zero requests is counted as 100% available. Microsoft Learn (2026) notes three additional measurement rules that catch customers off guard:
- Many contracts require requests to fail continuously for a minimum period, or require your application to retry failed requests with backoff intervals, meaning brief transient errors often do not count as official downtime (Microsoft Learn, 2026).
- When a provider calculates availability across all instances in an account or subscription rather than per resource, healthy instances offset failed ones and produce a higher official availability percentage than what an affected user experienced (Microsoft Learn, 2026).
- Standard cloud SLAs exclude scheduled maintenance windows, force majeure events outside the provider’s reasonable control, customer misconfigurations, free tiers, and preview features that have not reached general availability (Microsoft Learn, 2026; Google Cloud, 2026; Uptime.com, 2024).
Why do multi-zone and multi-service architectures have different targets?
Your contractual uptime target depends heavily on how you deploy your infrastructure and how many services sit in your application’s path. Providers reserve their highest commitments for workloads spread across multiple isolated data center zones.
Under the May 2022 Amazon Compute Service Level Agreement, running Amazon EC2 instances across two or more Availability Zones in a region qualifies for a 99.99% Region-Level SLA, whereas running a single EC2 instance drops your protection to a 99.5% Instance-Level SLA. Google Cloud’s Compute Engine SLA (2026) follows a similar split: instances deployed across multiple zones in most regions receive at least a 99.99% monthly uptime commitment (and at least 99.95% in the Stockholm region), while a single memory-optimized instance receives at least 99.95% and a single standard instance receives at least 99.9%.
When your workload chains multiple cloud services together in sequence, your overall availability drops below the lowest individual service target. As detailed in Microsoft Learn’s August 2024 Azure Well-Architected reliability guide “Architecture strategies for defining reliability targets”, composite availability is the product of each dependent component’s target percentage. While multiplying a 99.95% service by a 99.99999% service leaves composite availability near 99.95%, chaining a realistic multi-tier workload that includes a 99.80% managed SQL instance and multiple 99.99% components reduces the composite reliability target to 99.72% (Microsoft Learn, 2024). Microsoft Learn (2024, 2025) also notes that some foundational networking components, such as Azure virtual networks and network security groups, carry no published financial SLA, and enterprise database tiers pair uptime targets with Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) to measure how quickly data and service recover after a failure.
How do you claim a service credit after an SLA breach?
When a cloud provider misses its uptime target, standard public contracts from AWS (2022, 2026), Google Cloud (2026), and Microsoft (2026) do not pay cash refunds or reimburse lost business revenue. Your sole contractual remedy is a service credit applied against future bills for the affected service, calculated in stepped brackets rather than matching the exact duration of the outage.
On Google Cloud Compute Engine (for a 99.9% single-instance commitment) and AWS Continuum (2026), monthly uptime below 99.9% down to 99.0% earns a 10% credit, uptime below 99.0% down to 95.0% earns a 25% credit, and uptime below 95.0% earns a 100% credit for that month. On Amazon EC2 (2022), the middle tier pays a 30% credit for monthly uptime between 95.0% and 99.0%, and credits are issued only if the credit amount exceeds $1 USD. Because of those brackets, a 30-minute outage that breaches a 99.99% multi-zone SLA triggers a 10% credit on that month’s bill even though the outage lasted less than 0.1% of the month (AWS, 2022; Google Cloud, 2026; ClickHouse, 2026).
Aside from narrow exceptions, such as AWS automatically waiving the hourly charge whenever a single EC2 instance is unavailable for more than six minutes of a clock hour (AWS, 2022), providers do not issue SLA credits unless you file a claim. Following Microsoft Learn’s 2026 workflow and provider filing rules, take these four steps to claim a credit:
- Check your service tier and prerequisite settings before an incident occurs. Verify in your provider’s SLA documentation whether your resource is on a qualifying paid tier, whether it requires deployment across two or more Availability Zones, and whether errors are tracked by lost connectivity minutes or by HTTP 500 and 503 status codes (Microsoft Learn, 2026; AWS, 2022, 2026).
- Capture corroborating telemetry while the outage is happening. Export client-side and server-side logs showing exact start and end timestamps with time zones, affected instance or resource IDs, regions and Availability Zones, HTTP error codes, retry attempts with backoff intervals, and screenshots or links from the provider’s status dashboard (Microsoft Learn, 2026; AWS, 2022).
- Calculate net monthly uptime after subtracting exclusions. Remove any minutes tied to scheduled maintenance or non-redundant configurations, then run the monthly uptime percentage formula to confirm that availability dropped into a 10%, 25%, 30%, or 100% credit bracket (Microsoft Learn, 2026; Google Cloud, 2026; AWS, 2022). If your calculation stays above the monthly threshold because of account-wide aggregation, check whether single-hour billing waivers apply instead, such as the AWS six-minute clock-hour rule for single EC2 instances (Microsoft Learn, 2026; AWS, 2022).
- Submit a formal support ticket before the filing deadline expires. Open a billing or technical support request in your cloud console using the exact subject line required by the contract, such as “Amazon Compute SLA Credit Request – Region-Level Claim” on AWS, and attach your log files (AWS, 2022). You must submit the claim within 60 days of becoming eligible on Google Cloud Compute Engine (2026), or by the end of the second billing cycle after the incident occurred on AWS (2022), or you forfeit the credit.