Back to sensacat

Home  /  Learn

· SensaCat Team

What Is an Uptime SLA?

A contractual availability commitment backed by service credits. 99.9% allows nearly nine hours of downtime a year.

An uptime SLA, or service level agreement, is a contractual commitment from a provider to keep a service available for at least a stated percentage of a measurement period, with a defined remedy if they miss it.

The remedy is almost always a service credit against future billing, not compensation for your losses. This is the most important thing to understand about an SLA: it is a billing arrangement, not an engineering guarantee.

SLA, SLO and SLI are three different things

A service level indicator is the measurement itself, such as the percentage of successful requests. A service level objective is the internal target you hold yourself to. A service level agreement is the external contract, with money attached.

Mature teams set the internal objective tighter than the external agreement, so that missing the target is a signal rather than an invoice. An SLO equal to the SLA leaves no margin to react.

What each level of nines actually allows

Availability Per year Per 30-day month Per week
99% 3 days 15 hours 36 min 7 hours 12 min 1 hour 40 min 48 sec
99.5% 1 day 19 hours 48 min 3 hours 36 min 50 min 24 sec
99.9% (three nines) 8 hours 45 min 36 sec 43 min 12 sec 10 min 5 sec
99.95% 4 hours 22 min 48 sec 21 min 36 sec 5 min 2 sec
99.99% (four nines) 52 min 34 sec 4 min 19 sec 1 min 1 sec
99.999% (five nines) 5 min 15 sec 25.9 sec 6 sec

Four nines is the point where the annual budget is under an hour, which means a single unplanned restart can consume most of it. Five nines cannot be met by anything requiring human intervention, because 26 seconds a month is less than the time it takes to read a page.

The clauses that decide what the number means

What counts as downtime is the first. Most SLAs count only total unavailability, so a service responding in 40 seconds instead of 200 milliseconds is technically up and the SLA is technically met.

The measurement window is the second, and it resets. A monthly SLA means a four-hour outage on the 31st and another on the 1st fall in different periods, and neither may breach anything.

Exclusions are the third and usually the longest section. Scheduled maintenance, force majeure, third-party network problems, customer misconfiguration and beta features are commonly carved out, and scheduled maintenance is frequently unlimited.

Who measures is the fourth. The provider's own instrumentation is typically authoritative, which means your monitoring showing an outage is evidence for a conversation rather than a determination.

Credits are smaller than the loss

A typical structure returns 10% of the monthly fee for a modest breach, rising in bands, capped at somewhere around 100% of that month's charge. Claims usually have to be filed within a window, often 30 days, with supporting evidence.

A service costing $200 a month that takes your storefront down for six hours refunds a fraction of $200. The mismatch is the point: the credit is a penalty designed to create incentive, not an indemnity.

Dependencies multiply

If your application depends on three services each committing to 99.9%, and their failures are independent, your combined ceiling is about 99.7%. That is roughly 26 hours a year rather than the 8 hours 46 minutes each contract implies.

Your own SLA cannot exceed the composite of everything you depend on unless you build redundancy that removes a dependency from the critical path. Promising four nines on top of three-nines infrastructure is a promise about accounting, not availability.

Detection speed feeds directly into these numbers; see what is a grace period. For outages that never register as downtime at all, see what is a silent failure.