Aivorab
Editorial illustration: API Uptime SLA Explained: What 99.9% Really Means for Your Stack

API reliability · SLA explained · SLO vs SLA · uptime calculations · third-party dependencies · error budgets

API Uptime SLA Explained: What 99.9% Really Means for Your Stack

A grounded guide to reading API uptime SLAs, understanding SLOs versus SLAs, decoding exclusions and credits, and why third-party reliability guarantees compound in ways most developers miss.

Published:

The Number on the Page Is Not the Number in Your Logs

When you pick a third-party API, the first thing you notice is the uptime percentage. 99.9%. 99.95%. 99.99%. It looks like a badge of confidence. But the gap between what that number promises and what your application actually experiences is where most reliability problems begin.

This article walks through what uptime SLAs actually measure, how SLOs differ from SLAs in practice, how to read the exclusions and credits clauses that determine whether a guarantee is real, and why the math of combining multiple API dependencies is almost always worse than any single provider advertises.

What 99.9 Percent Uptime Actually Means

A 99.9% uptime SLA allows approximately 43 minutes and 49 seconds of downtime per month, or roughly 8 hours and 46 minutes per year. A 99.95% SLA allows about 21 minutes and 54 seconds per month. A 99.99% SLA allows just over 4 minutes and 22 seconds per month.

These are theoretical maximums calculated against a standard billing cycle. They do not account for scheduled maintenance windows that may be excluded, partial outages that affect only some requests, or the compounding effect when your application depends on more than one service.

The difference between 99.9% and 99.99% is not incremental. It is the difference between roughly 8 hours of annual downtime and roughly 52 minutes. For an API your application calls on every user action, that gap is the difference between a service that feels reliable and one that frustrates users regularly.

SLO versus SLA: Two Different Promises

The terms are often used interchangeably in casual conversation, but they serve different functions and carry different weight.

An SLO, or Service Level Objective, is an internal target. It is the level of reliability your team commits to delivering to your users. Google SRE practice defines an SLO as a precise numerical target for system availability that frames every discussion about whether the system is running sufficiently reliably. The key principle is that you define the lowest level of reliability you can get away with for each service. Higher reliability costs more to operate, so the SLO is a deliberate trade-off, not an aspirational goal.

An SLA, or Service Level Agreement, is an external contract. It is the promise a provider makes to you, usually with financial consequences if it is broken. SLAs are typically expressed as uptime percentages with defined credit tiers. AWS, for example, offers a Region-Level SLA of 99.99% for EC2 deployed across multiple availability zones and an Instance-Level SLA of 99.5% for individual instances. The credit structure is tiered: falling below 99.99% but above 99.0% earns a 10% credit, below 99.0% earns 30%, and below 95.0% earns 100%.

The practical distinction matters because your internal SLO and a provider’s external SLA are not the same thing. Your SLO should be set based on what your users experience. The provider’s SLA is a baseline guarantee that may include exclusions, measurement methodologies that favor the provider, and compensation that rarely covers the real cost of downtime to your business.

Reading SLA Exclusions and Credits

The fine print in an SLA is where the real terms live. Most providers exclude scheduled maintenance, force majeure events, and sometimes even partial degradation from their uptime calculations. A service that returns 503 errors for half your requests during an incident may still count as available under certain measurement definitions.

When evaluating an SLA, look for these specific elements:

How availability is measured. Is it server-side request success rate, where the provider counts successful responses from their infrastructure? Or is it client-side, where failures to reach the service are included? Server-side metrics miss network-level failures, DNS issues, and client timeouts. Client-side measurements, sometimes called canary checks, simulate actual user traffic and capture the full experience.

What is excluded. Scheduled maintenance is the most common exclusion. Some providers exclude maintenance windows entirely from the availability calculation. Others count them as downtime. The distinction determines whether a provider can schedule extended outages without triggering credits.

The credit structure. Credits are typically a percentage of your monthly bill for the affected service. They are almost never cash refunds. They are applied as future service credits. A 10% credit on a $500 monthly bill is $50 in credits, not $50 back in your bank account. For a small team, that may feel like a meaningful gesture. For an outage that costs your business thousands in lost revenue, it is symbolic at best.

The claim process. Some providers require you to request credits within a narrow window. Others apply them automatically. AWS notes that instances unavailable for more than six minutes in a clock hour are automatically credited, but most SLAs require proactive claims.

The Compound Math of Third-Party Dependencies

Here is where most developers get surprised. Application availability follows probability rules. When your application depends on multiple services, all of them need to be operational for your application to function. This creates a multiplicative effect on availability calculations.

Consider an application that depends on two services: one with a 99.95% SLA and another with a 99.99% SLA. The overall availability is not the average. It is 0.9995 multiplied by 0.9999, which equals 99.94%. You have already lost 0.05% availability compared to your weakest link.

The effect compounds rapidly as you add dependencies:

Ten dependencies, each individually rated 99.9%, produce an application availability of 99.0%. That is nearly 9 hours of downtime per year instead of the 8.8 hours any single service would allow. The math does not care about your architecture choices. It only cares about how many independent points of failure exist in your request path.

This is why multi-region deployments and fallback strategies are not optional extras. They are the only way to break the multiplicative chain. If one API region fails, a secondary region can keep serving requests and preserve the availability of the whole system.

Partial Failure: The Hidden Reliability Problem

Availability is often treated as a binary condition. The service is up or it is not. But real failure is rarely so clean. A service may be partially degraded, serving only some requests, responding slowly to others, or failing only for users in certain regions.

Google SRE practice emphasizes that failure has a degree of impact and is often experienced in some subset of the workload. It may affect a percentage of users, a percentage of requests, a percentage of locations, or a percentile of latency. These are partial failure modes, and they are the most common source of user-facing reliability problems.

An SLA that measures availability as server-side request success rate will not capture partial failures that occur before requests reach the provider’s infrastructure. A client-side measurement using canary probes will catch more of these cases, but even that approach has blind spots. It measures from the probe’s location, not from every user’s location.

When evaluating a third-party API, ask how the provider measures availability and whether their definition matches the experience your users actually have. A provider that reports 99.99% availability based on server-side metrics may be experiencing partial failures that your users feel acutely.

Designing Your Own SLOs Before You Choose Providers

The most practical step you can take is to define your own SLOs before you evaluate third-party guarantees. Google SRE guidance recommends bringing together product, development, and reliability teams to achieve a common understanding of the workload, particularly its critical user journeys. Write down detailed sequence diagrams for these journeys. Identify where users may choose not to take an action, which parts you can measure, and which parts depend on third parties you cannot control.

Frame your SLO design around the question: what do my users care about? This prevents you from optimizing for metrics that look good on paper but do not reflect actual user experience. It also forces you to confront the dependencies you cannot measure directly.

Once you have your SLOs defined, you can evaluate third-party APIs against them. Ask providers how they measure availability, what is excluded, how credits work, and whether they support multi-region or fallback architectures. The SLA number on the first page is the starting point, not the answer.

FAQ

Is a 99.9% SLA good enough for a production API? It depends on your SLO. 99.9% allows about 43 minutes of downtime per month. If your application cannot function during an outage, and the outage costs you more than the credit you would receive, you need a higher guarantee or a fallback strategy. No single SLA number is universally sufficient.

Do service credits actually compensate for downtime? Almost never. Credits are typically a small percentage of your monthly bill and are applied as future service credits, not cash refunds. The real cost of downtime to your business is almost always far higher than the credit you would receive.

Should I trust a provider’s server-side availability metrics? Use them as one data point, not the final word. Server-side metrics miss client-side failures, network issues, and partial degradation. If possible, measure availability from your own infrastructure using canary checks or client-side monitoring.

How do I protect against third-party API failures? Implement retry logic with exponential backoff, cache responses when appropriate, design fallback paths that degrade gracefully, and consider multi-region or multi-provider strategies for critical dependencies. No third-party API is infinitely reliable, and your architecture should reflect that reality.

Sources