08 — Monitor & Observe

Alerting & SLOs#

ReliabilityPractice 1 min read
◆ The PatternLatency budgets, error budgets, and avoiding alert fatigue

A Service Level Objective (SLO) defines what "good enough" means: "99.5% of predictions return within 200ms." The error budget is what's left — you can spend it on risky deployments. Too many alerts and people ignore them; too few and incidents go unnoticed.

Error Budget = 1 − SLO target
If your SLO is 99.5% availability, your error budget is 0.5% — roughly 3.6 hours of downtime per month.
// Interactive — error budget burn rate
SLO Target %99.5%
Pattern bridge: Error budgets work like drawdown limits in trading — a predefined loss tolerance that triggers defensive action when consumed. The statistical foundation is the same confidence interval logic.
Worked example

An SLO of 99.5% over 30 days and 10 million requests allows 50,000 failures — the error budget. If the error rate is now 2%, the budget burns 4× faster than allowed and is gone in 7.5 days. Alerting on burn rate, not on the raw error rate, pages people for what threatens the objective and nothing else.

Where it misleads
  • An SLO nobody agreed to is just a threshold; the budget only works if it changes decisions, such as freezing risky releases.
  • For ML, “success” must include quality, not only uptime: a fast, wrong prediction meets a latency SLO.
  • Alerts on short windows alone are noisy, on long windows alone are late; the SRE workbook combines both.
In code
slo = 0.995                            # 99.5% of requests succeed within 200 ms, over 30 days
requests = 10_000_000
budget = (1 - slo) * requests          # failures you are allowed in the window
error_rate = 0.02                      # what is happening right now
burn = error_rate / (1 - slo)          # how many times faster than allowed
days_left = 30 / burn                  # budget gone at this pace
Python, in your browser — edit the code and run it again

Assumes import numpy as np and import pandas as pd. Each snippet carries its own example numbers; the comments say which are made up or simulated.

Sources
  • Site Reliability Engineering: How Google Runs Production Systems, B. Beyer, C. Jones, J. Petoff & N. R. Murphy (eds.), O’Reilly, 2016
  • The Site Reliability Workbook, B. Beyer, N. R. Murphy, D. K. Rensin, K. Kawahara & S. Thorne (eds.), O’Reilly, 2018 — “Alerting on SLOs”

Last reviewed October 2026 · How this site checks its content · Report a mistake

Check yourself

1. A service has a 99.9% monthly availability SLO. How much downtime does the error budget allow in 30 days?

Show answer

A. 0.1% of 30 × 24 × 60 = 43,200 minutes is 43.2 minutes.

2. Why not page someone on every single error?

Show answer

C. Burn-rate alerts fire when the current error rate would use up the budget well before the period ends.

3. Besides latency and errors, what should an ML service’s indicators include?

Show answer

C. A model can return fast, valid, wrong answers. Quality indicators catch what availability metrics cannot.

Linked from 1
← Previous
Model Monitoring Dashboards
Open in the full reader, with the topic sidebar