What is an SLA? Uptime SLAs and the nines, explained

An SLA, or service level agreement, is a commitment from a provider about the level of service you can expect, usually stated as an uptime percentage such as 99.9%. It defines how that service is measured, what does not count against it, and what you are owed if the provider falls short. In short, it turns a vague promise of "reliable" into a number you can hold someone to.

SLAs show up on both sides of most software businesses. You rely on the uptime your hosting provider, payment processor and APIs promise you, and your own customers rely on the uptime you promise them. Understanding how the number is built, and where the fine print hides, is what keeps an SLA from being marketing.

SLA, SLO and SLI

Three closely related terms travel together, and it helps to keep them straight.

• SLI, service level indicator: the raw measurement. For uptime, this is the percentage of successful checks or requests over a period. It is a fact about what happened.
• SLO, service level objective: your internal target for that indicator, for example "99.95% of requests succeed each month." It is the line you are aiming to stay above.
• SLA, service level agreement: the external, contractual promise, with consequences attached if you miss it.

A common pattern is to set the SLA a little looser than the SLO. If your internal objective is 99.95%, you might promise customers 99.9%. That gap is deliberate headroom: it means you can miss your own target slightly and start fixing it before you owe anyone a credit.

The nines: what an uptime percentage really allows

Uptime SLAs are often described by their "nines," and the shorthand hides how much downtime each level actually permits. Every additional nine cuts the allowed downtime by roughly ten times. Here is what the common levels work out to.

• 99% (two nines): about 3.65 days of downtime per year, or roughly 7.3 hours per month.
• 99.9% (three nines): about 8.8 hours per year, or roughly 44 minutes per month.
• 99.95%: about 4.4 hours per year, or roughly 22 minutes per month.
• 99.99% (four nines): about 53 minutes per year, or roughly 4.4 minutes per month.
• 99.999% (five nines): about 5.3 minutes per year, or roughly 26 seconds per month.

Two things jump out. First, 99% sounds high but permits days of outage a year, which is why it is rarely good enough for anything people depend on. Second, the jump from three nines to five is enormous in engineering terms: you go from a comfortable 44 minutes a month to a budget so tight that a single slow deploy can blow it. Each nine is far more expensive to reach than the last.

Reading an SLA properly

The headline percentage is the part everyone quotes. The clauses around it are the part that decides what the number is worth.

• What counts as downtime. Does the SLA measure a full outage only, or does severe degradation count too? A service that is up but unusably slow may technically satisfy a naive uptime clause.
• The measurement window. A percentage is meaningless without a period. 99.9% measured monthly resets your downtime budget every month; measured annually, a single bad day can be absorbed by the rest of the year. Shorter windows are stricter.
• Exclusions. Scheduled maintenance is almost always excluded, and so are outages caused by your own configuration, third parties, or force majeure. Planned maintenance windows can quietly remove hours from what the SLA actually guarantees.
• Who measures it. If the provider is the sole judge of their own uptime, the number is only as trustworthy as their reporting. This is a strong argument for measuring independently, which we come back to below.

Service credits, not refunds

When a provider misses its SLA, the remedy is usually a service credit: a percentage of your bill applied to a future invoice, scaled to how badly they missed. It is rarely a cash refund, and it rarely comes close to covering what an outage actually cost your business.

Two practical catches are worth knowing. Credits are often not automatic: you may have to notice the breach and request the credit within a set window, or you forfeit it. And the credit is capped, typically at a fraction of the monthly fee. An SLA is a statement of intent and a modest insurance policy, not a guarantee that outages will be made whole.

Error budgets: the SLA as a tool, not a threat

Mature teams turn the SLA around and use it to make decisions. If your objective is 99.9% monthly, you have about 44 minutes of allowed downtime a month. That is your error budget, and it is a resource to spend deliberately.

When the budget is healthy, you can ship faster and take more risk, because you have room to absorb a mistake. When you have burned most of it, you slow down, freeze risky changes, and focus on stability. The error budget reframes reliability from "never fail" to "fail within a known allowance," which is both achievable and honest. How fast you recover from each failure, your mean time to recovery, directly determines how much of that budget each incident spends.

Why you have to measure it yourself

Every SLA rests on measurement, and you cannot hold a provider, or yourself, to a number nobody is independently tracking. If your only source of truth is the provider's own status page, you are trusting the graded party to grade themselves.

Independent uptime monitoring gives you your own record of when a service was reachable and when it was not, from outside the provider's own network. That record is what lets you verify a vendor's SLA claims, and what lets you report your own uptime to customers with evidence behind it. Confirming outages from more than one location matters here too, so a single bad network path does not corrupt your figures. A monitor also captures the raw uptime an status page then communicates to your users, and you can spot-check any URL right now with the free is it down checker. If uptime monitoring itself is new to you, start with what is uptime monitoring.

The takeaway

An SLA is only as strong as its definition and its measurement. Read past the headline nines to the window, the exclusions and the credit terms, decide what level you genuinely need rather than the most impressive number, and measure uptime independently so the promise is backed by evidence.

Start monitoring free, no credit card, and build your own record of uptime instead of taking a status page on trust.