What Is an SLO? A Plain-English Guide With a Sheets Tracker

So, what is an SLO? A service level objective is a reliability target you set for a service, written as a number over a time window. "99.9% of requests succeed over 30 days" is an SLO. It tells your team how much failure is acceptable before you stop shipping and start fixing. The math behind it is plain division, which is why a spreadsheet handles it fine.

Biscuit has already fetched the formulas. You bring the numbers.

The three acronyms you keep seeing, sorted out

SLI, SLO, SLA. People mix them up in meetings, so here is the short version.

• SLI (service level indicator): the thing you measure. Share of requests that return without an error, share of pages that load under 300 ms, share of jobs that finish on time.

• SLO (service level objective): the target for that measurement. "The SLI must be at least 99.9% over 30 days."

• SLA (service level agreement): a contract with consequences, usually money back, attached to a target.

The cleanest test comes from Google's SRE book: ask what happens if you miss the target. If nothing contractual happens, you are looking at an SLO, not an SLA. Your SLO should be tighter than any SLA you have signed, so you get a warning before a customer gets a refund.

In spreadsheet terms: the SLI is a column of measurements, the SLO is one cell with the target, and the SLA is a PDF somebody in legal keeps.

Why 99.9% and 99.99% are very different promises

Every extra nine cuts your allowed downtime by a factor of ten. Over a 30-day month (43,200 minutes), here is what each target leaves you:

• 99%: 1% budget, 432 minutes (7.2 hours) of allowed downtime per 30 days

• 99.5%: 0.5% budget, 216 minutes (3.6 hours)

• 99.9%: 0.1% budget, 43.2 minutes

• 99.95%: 0.05% budget, 21.6 minutes

• 99.99%: 0.01% budget, 4.32 minutes

That last line is the trap. Four minutes a month means a human cannot even finish reading the alert before the budget is gone. Most internal tools, dashboards and small SaaS products do not need it, and chasing it costs real money in redundancy and on-call hours.

Skip 99.99% unless a customer is paying you specifically for it. Google's advice is blunt too: start with a loose target you can tighten later, because a strict one you have to relax teaches everyone to ignore the number.

The error budget: the number your team actually argues about

The error budget is whatever the SLO leaves over. Target 99.9%, so the budget is 0.1%. Over 30 days, that is 43.2 minutes of "bad" time you are allowed to spend.

Think of it as a fuel gauge. Risky deploys burn fuel. A bad database migration burns fuel. An outage at 3 a.m. burns a lot of fuel. When the tank is full, ship faster. When it is empty, stop adding features and fix reliability.

Google's own sample policy is concrete about it: if a service blows its budget over a four-week window, all changes stop except P0 fixes and security patches until the service is back inside its SLO. The budget is a negotiation tool, not a punishment. It lets a product manager and an engineer argue from the same cell instead of from gut feeling.

Worth the trouble if you have more than one team touching the same service. Overkill if you are a solo founder with one landing page and a contact form.

Picking an SLI your users would recognize

The best SLIs describe a moment a person would notice. Three cover most services:

• Availability: the share of requests that succeed. Easy to measure, easy to explain.

• Latency: the share of requests faster than a threshold. "95% of searches return in under 300 ms" is better than an average, because averages hide the slow tail that annoys people.

• Freshness: for data pipelines and reports, the share of runs that finish before the deadline. This one fits spreadsheet people well: "the morning sales sheet is updated by 8 a.m. on 99% of weekdays."

Write the SLI as a fraction: good events divided by valid events. That one habit makes every SLO calculable in a single cell, and it forces you to decide what counts as "good" before the incident, not during it.

For the window, a rolling 30 days is the usual pick. A calendar month is simpler to report but resets the budget on the 1st, which tempts teams to push risky releases at month end. In a sheet, a rolling window just means filtering the Incidents tab to the last 30 days with SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

Build an SLO tracker in Google Sheets or Excel in 10 minutes

You do not need a monitoring platform to start. You need two tabs: Incidents and SLO.

On the Incidents tab, log every outage with a start time in column A, an end time in column B, and the duration in column C:

=(B2-A2)*24*60

• B2 and A2: the end and start date-times of the incident.

• *24*60: turns the day-based difference into minutes.

Works in both Excel and Sheets, all versions.

Now the SLO tab. Put these labels in column A and the formulas in column B:

B1: 0.999                         (your SLO target)
B2: 30                            (window in days)
B3: =B2*24*60                     (total minutes in the window)
B4: =B3*(1-B1)                    (error budget in minutes)
B5: =SUM(Incidents!C2:C)          (downtime so far)
B6: =1-B5/B3                      (actual availability)
B7: =B4-B5                        (budget left, in minutes)
B8: =B5/B4                        (share of budget burned)

With a 99.9% target, B3 returns 43200 and B4 returns 43.2. Log a 12-minute outage and B8 shows 27.8%. Voilà ce que ça donne dans une vraie cellule.

A note on C2:C in B5: the open-ended range is Sheets syntax. In Excel, use a fixed range like Incidents!C2:C500 or a table reference.

Add a status cell so nobody has to read the number:

=IF(B8>=1,"Freeze releases",IF(B8>=0.5,"Careful","Ship it"))

• B8>=1: budget fully spent or overspent.

• B8>=0.5: half gone, so review risky changes.

• Anything else: green light.

Pick your own thresholds. Fifty percent is a starting guess, not a law of physics.

Stuck on the syntax for your own version of this sheet? Describe it in plain English and let the tool write it.

Counting requests instead of minutes

Time-based tracking is easy to explain but crude. If your service is "down" for 5 minutes at 4 a.m. when nobody is online, that hurts less than 5 minutes at noon. Most serious teams define the SLI by requests instead.

Paste an export of your request log into a tab, with the HTTP status code in column B. Then:

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

• COUNTIF(B2:B,">=500"): counts requests that returned a server error.

• COUNTA(B2:B): counts all requests. One minus the error share gives you the success share.

The result is your availability SLI as a fraction. Compare it to the target cell and you have the whole SLO in one line. Excel 2016 and 365 both accept COUNTIF; just swap B2:B for a bounded range.

Two honest warnings. Spreadsheets choke on millions of rows, so export daily totals instead of raw logs. And a 4xx response is usually the user's mistake, not your outage, so decide that rule once and write it down.

Burn rate: the formula that warns you before it is too late

Knowing you burned 27.8% of your budget is nice. Knowing you are burning it faster than the calendar is useful. That ratio is the burn rate.

=B8/(B9/B2)

• B8: share of budget burned so far.

• B9: days elapsed in the window (enter it manually or use =TODAY()-B10, with the window start date in B10).

• B2: total window in days.

A burn rate of 1 means you will finish the window with exactly zero budget left. Above 1, you are heading for a freeze. Below 1, you have room. If you are 10 days into a 30-day window and already burned 60%, the burn rate is 1.8. That is the number to put on a screen.

This is the same idea the big monitoring tools use for burn-rate alerts. A sheet will not page you at 3 a.m., though, so treat it as a reporting layer, not an alarm.

Here is a worked example with real numbers. Your SLO is 99.9% over 30 days, so the budget is 43.2 minutes. Day 1 to 8: a bad deploy takes the checkout page down for 14 minutes. That is 32.4% of the budget gone in a quarter of the window, a burn rate of about 1.2. Nothing is on fire, but the sheet now says "Careful", and the next risky migration gets a second look. Day 15: a provider outage adds 30 minutes. Total 44 minutes, 101.9% burned. The status cell flips to "Freeze releases", and the conversation about priorities happens with a number on the table instead of a feeling.

That is the whole value of the exercise. Not the nines, but the shared cell everyone can point at.

When the spreadsheet stops being enough

A tracker like this works for one or two services and a weekly review. It breaks down when you have dozens of services, need automatic data collection, or want alerts that fire in minutes rather than at the next Monday meeting.

Time to look at a proper observability tool. Datadog and Grafana both have native SLO features that pull the SLI straight from your metrics and draw the budget for you.

Pick Grafana if you want open source and already run Prometheus. Pick Datadog if you would rather pay to not run anything yourself. Either way, keep the sheet around for the monthly review deck, because everybody in the room can open it and nobody needs a login to a vendor.

If you want help drafting a first set of SLIs for a service, a general assistant is a decent brainstorming partner. Verify every number it gives you, since it will happily invent a plausible-sounding target.

Mistakes that make an SLO useless, and what to do on Monday

A few patterns that Biscuit has seen end badly:

• Copying your current performance as the target. If you ran at 99.97% last quarter, an SLO of 99.97% locks in a pace you may not be able to sustain.

• Too many SLOs. Two or three per service. Past that, nobody remembers which one matters.

• Measuring what is easy, not what users feel. CPU usage is not an SLI. Failed checkouts are.

• No consequence. An SLO without an error budget policy is a wish. Decide in advance what happens at 50%, 100% and 150% burned.

• Never revisiting the target. Review it every quarter. If you never come close to spending the budget, the target is too loose.

Now the Monday part. Pick one service. Write down one SLI in a single sentence a non-engineer could follow. Set a loose target, 99.5% or 99.9%. Build the two tabs above, log last month's incidents, and see what the budget says.

If the answer is "we burned 300% of it", you just found out why everybody feels tired. If the answer is "we burned 4%", tighten the target or ship faster. Either way, you now have a number to argue about instead of a feeling.

Good boy. Now go and log those incidents.