SLA, SLO and SLI: understanding and calculating uptime

A client asks you to guarantee 99.9% uptime. The number sounds reasonable, modest even. But do you know how many minutes of downtime it leaves you each month, what counts as an outage, and how you will prove you kept your word?

This guide sets out the definitions, the formula and allowed downtime, walks through a worked example, then helps you choose a target and write solid contract clauses.

SLA, SLO and SLI: three ideas, three jobs

The SLI is the measurement

An SLI (Service Level Indicator) is something you measure: the percentage of successful checks on your home page, the share of API requests served without a 5xx error, or the proportion of pages loaded in under a second. It is a fact, not a goal: "in September, the site answered correctly from the outside 99.94% of the time".

The SLO is the internal target

An SLO (Service Level Objective) is the target your team sets on an SLI over a given period: "99.9% uptime over a calendar month". It is a steering tool: while it holds, you keep shipping; when it is at risk, you slow down and harden things.

The SLA is the contractual commitment

An SLA (Service Level Agreement) is the promise you make to the customer, with consequences if you break it, usually service credits. It is normally less ambitious than the SLO: with an internal target of 99.9%, you might commit to 99.5% and keep a margin between the moment your team reacts and the moment you start owing money.

The formula and allowed downtime

The formula

The calculation fits on one line:

uptime (%) = (measured time − downtime) / measured time × 100

Measured time is the reference period, minus maintenance windows if the contract excludes them. Downtime is the sum of qualifying outages. The hard part is agreeing on those two definitions, not the division.

Common targets at a glance

Calculated on an average month of 30.44 days and a 365-day year, rounded to the second:

Every extra "nine" cuts allowed downtime by a factor of ten. Going from 99.9% to 99.99% takes you from three quarters of an hour to four minutes a month: barely enough time to receive the alert and open your laptop. For other values, per day, week or quarter, use our free SLA calculator.

Worked example and error budget

A month with incidents

Take September, 30 days or 43,200 minutes, for an online shop with a 99.9% SLO:

• on the 3rd, a saturated database causes a confirmed 18-minute outage;
• on the 17th, a faulty deployment takes the site down for 7 minutes;
• on the 24th, a scheduled, announced maintenance lasts 40 minutes;
• several times, the site is slow but responding, about 2 hours in total;
• one night, a single probe sees errors while the others see the site up.

If the contract excludes maintenance and only counts confirmed outages, measured time is 43,200 − 40 = 43,160 minutes and downtime is 18 + 7 = 25 minutes:

(43,160 − 25) / 43,160 × 100 = 99.942%

The SLO is met. If maintenance counts as downtime, you get (43,200 − 65) / 43,200 = 99.850% and the target is missed. Same month, same service, opposite conclusions: everything needs to be written down in advance.

The error budget

The error budget is the amount of unavailability your target allows: 43 min 50 s for 99.9% over an average month. In our example, with 43,160 minutes measured, it comes to 43.16 minutes, of which 25 were used, or 58%.

Rather than aiming for zero outages, the team has a budget to spend. Plenty left halfway through the month? Ship that slightly risky migration. Nearly gone? Freeze non-urgent releases. The Embracing Risk chapter of Google's SRE book covers the mechanics.

What counts as downtime

This is behind most disputes, and there is no universal answer.

Confirmed outages always count, as long as they are real: a single failure seen from one probe is often a local network issue. Requiring confirmation by a majority of regions keeps downtime figures honest, as we explain in our guide to avoiding false positive alerts with multi-region checks.

Degraded performance is a grey area. A site that takes 12 seconds to render a page is technically available, but not for the user. Some contracts ignore slowness, others set a response time threshold beyond which a minute counts as lost. Pick one, and write it down.

Scheduled maintenance is usually excluded, provided it was announced with a defined notice period (72 hours, say) and stays under a monthly cap. Without a cap, ten hours of "maintenance" a month would empty the SLA of any meaning.

External causes (customer-side faults, force majeure, explicitly named third-party providers) are standard exclusions, open to negotiation.

Measure from the outside and from several regions

An SLA is only worth something if it is measured in a way the customer can accept. Internal server metrics are not enough: an unreachable machine reports nothing, and a DNS or certificate failure goes unnoticed. Measurement has to come from the outside, the way your users experience the service.

Several measuring regions make the result fairer: an outage seen from Paris, Amsterdam and Warsaw is a real outage, while a failure seen from one location may come from the network between that probe and you. That is how LucidStack's multi-region monitoring works: when a check fails, the monitor's other regions recheck immediately, and an outage is only declared if a majority fail.

Frequency matters too. With a check every 5 minutes, each outage is measured with several minutes of uncertainty, which is incompatible with the 4 min 23 s a month of a 99.99% target. Beyond 99.9%, you need checks every minute or every 30 seconds.

Composite uptime of dependent services

Your website relies on a host, a database, a payment provider, a DNS service. When components are in series, meaning any single one failing makes the service unusable, their uptimes multiply:

99.95% × 99.9% × 99.9% = 99.75%

Three respectable building blocks add up to 99.75%, close to 1 h 50 min of possible downtime a month: you cannot promise 99.9% on top of that.

Redundancy works the other way: two independent components at 99.9% running in parallel give, in theory, 1 − (0.001 × 0.001) = 99.9999%. But failures are rarely independent (same provider, same configuration, same deployment), so treat that figure as an optimistic ceiling.

Choosing a realistic target

Start from your history: if your measured uptime over six months hovers around 99.93%, a 99.9% SLO is achievable and a 99.99% SLA is not. Then factor in your architecture and your team:

• a website or SaaS on a single infrastructure can reasonably aim for 99.5% to 99.9%;
• 99.95% assumes redundancy and zero-downtime deployments;
• 99.99% also requires a responsive on-call rota at any hour and detection in under a minute.

Every extra nine is paid for in infrastructure and sleepless nights: keep a gap between the internal SLO and the contractual SLA.

Writing SLA clauses

A solid SLA answers at least these questions:

• Scope: which services, URLs or API endpoints are covered.
• Measurement method: external monitoring tool, regions, check frequency, outage confirmation rule, time zone and reference period.
• Definition of downtime: accepted response codes, timeout, how degraded performance is treated.
• Exclusions: announced and capped maintenance, causes attributable to the customer, force majeure, named third-party dependencies.
• Service credits: tiers (for example a percentage of the monthly fee depending on how far below target you fall), overall cap, whether credits are the sole remedy.
• Claims: deadline to submit one, supporting evidence, which data source is authoritative.

A monthly report shared with the client, like LucidStack's client reports with uptime, incidents and response times, gives both sides a common reference.

In short

The SLI measures, the SLO guides the team, the SLA commits you to the customer. The formula is simple; the definitions are not. Decide in advance what counts as an outage, how you measure it and what you exclude. LucidStack measures uptime from three European regions, counts only confirmed outages, excludes your maintenance windows and includes the figures in its monthly reports (from the Solo plan). The Free plan is enough to start building the history that will help you choose your next target.