An SLO is useful only when it changes a decision
A dashboard target that never affects alerting, release pace, incident work or investment is a reporting ornament. Six numbers and structures the playbook is built on:
Fast burn pages fast
At 14.4 times the allowed rate, a 99.9% SLO spends 2% of its 30-day error budget in one hour. That is the threshold that should wake someone up.
The budget is the point
A 99.9% objective permits 0.1% bad events - 10,000 per 10 million eligible requests. The playbook turns that fraction into release and incident policy.
Three budgeting methods
OpenSLO v1 defines Occurrences, Timeslices and RatioTimeslices budgeting. The worked example uses the current schema, not the old v1alpha one.
Paired windows, fewer false pages
Long and short observation windows are paired so sustained threats page quickly without keeping alerts open long after recovery.
Eight failure modes, named
From measuring what is easy instead of what matters, to budgets without policy, to SLOs used for individual performance - each with the fix.
A 90-day rollout
Scope, instrument, set the objective, observe silently, connect operations, adopt policy. Six fifteen-day phases from zero to a working system.
The multi-window burn-rate alert table
For a 99.9% objective on a 30-day window, Google's canonical tiers. The playbook shows the arithmetic behind each row and how to recompute it for any target.
| Burn rate | Budget consumed | Long window | Short window | Action |
|---|---|---|---|---|
| 14.4x | 2% of the 30-day budget in 1 hour | 1 hour | 5 minutes | Page |
| 6x | 5% of the 30-day budget in 6 hours | 6 hours | 30 minutes | Page |
| 1x | 10% of the 30-day budget in 3 days | 3 days | 6 hours | Ticket |
A burn rate of 1 consumes the budget exactly at the allowed pace. Severity tiers are alertable conditions, not SLO breaches - the objective is still measured over the full window.
Alerting on attainment pages too late - or never stops paging
An alert that fires when the SLO is already breached tells you about harm after it happened, and a raw error-rate threshold pages on noise. Burn-rate alerts fire while the budget is being spent, at a speed proportional to the threat. The playbook derives both failure modes before it gives you the fix.
Eight parts, 34 numbered sections
Written for the people who get paged - and the people who decide
SRE & platform teams
You own alerting and want pages tied to user harm, with thresholds you can defend in a review.
Engineering leaders
You want reliability to be a decision input for release pace and investment, not a dashboard ornament.
On-call responders
You want every page to name the budget threat and link a runbook, so 3 AM has a script.
Teams adopting OpenSLO or OpenTelemetry
You want declarative examples checked against the current spec, not a blog post from three versions ago.
From no SLOs to a working budget policy
Pick one service
- Choose a user journey that matters
- Draft the SLI and eligible events
- Name the measurement boundary
Count good and bad
- Emit eligible and good-event metrics
- Keep dimensions to investigate failure
- Validate counts against reality
Set target and window
- Pick the target from evidence
- Choose rolling or calendar window
- Write the SLO document
Measure silently
- Record burn rates, no pages yet
- Compare alerts against incidents
- Tune thresholds before they fire
Wire the alerts
- Route pages and tickets by tier
- Attach runbooks to every alert
- Brief the on-call rotation
Make it policy
- Adopt the error-budget policy
- Start the review cadence
- Extend to the next service
Vendor-neutral method, vendor-authored, labeled as such
Read this before you cite us
This playbook is built from primary sources: Google's Site Reliability Engineering book and The Site Reliability Workbook for the quantitative method, the OpenSLO v1 specification for the declarative examples, IETF RFC 9544 for high-availability precision, and official vendor documentation for every product claim - checked on 18 September 2026.
KloudMate sells an observability platform with its own SLO features, and KloudMate appears in the implementation landscape. It is described only by what its own documentation documents - limits included, such as pre-aggregated APM span metrics and service-scoped incident matching in v1. Where a vendor's own docs contradict themselves, the playbook reports the list without papering over it.
There are no invented adoption statistics here. Where the evidence is thin - low-traffic services, AI quality SLIs, adapter support - the text says so. If our reading of a source is wrong, tell us; we publish corrections.
Common questions
What is an error budget?
The allowed bad-event fraction implied by an SLO: 1 minus the target. A 99.9% objective permits 0.1% bad events - at 10 million eligible requests in a 30-day window, that is 10,000 bad requests. The playbook treats the budget as a decision input for releases, incident work and investment, not as permission to fail.
What burn rate should page someone?
Google's multi-window, multi-burn-rate approach: 14.4x burn (2% of a 30-day budget in one hour) pages over paired 1-hour and 5-minute windows; 6x (5% in six hours) pages over 6-hour and 30-minute windows; 1x (10% in three days) opens a ticket over 3-day and 6-hour windows. The playbook shows how to recompute every tier for your own target.
Should SLOs use rolling or calendar windows?
Rolling windows suit alerting and budget math; calendar windows suit business reporting and weekly or monthly reviews. The playbook covers both, including how fixed and rolling implementations differ across the major platforms.
Do I need a specific observability vendor to use this playbook?
No. The method is vendor-neutral, and the worked examples use the OpenSLO v1 specification and Prometheus-style recording and alert rules. A landscape section covers what Google Cloud, AWS, Datadog, Grafana Cloud, New Relic, Azure and KloudMate each document, so you can map the method onto what you already run.
Is this playbook independent research?
No. It is vendor-authored by KloudMate, built from primary sources: Google's SRE book and workbook, the OpenSLO specification, IETF RFC 9544, and official vendor documentation. KloudMate appears in the landscape described only by its own documented behavior, and uncertain areas are labeled in the text.
Every claim is cited
All 19 source notes are listed in the playbook with access dates. The primary ones:
- Google, Site Reliability Engineering (the SRE book)
- Google, The Site Reliability Workbook - alerting on SLOs
- OpenSLO specification, current v1 schema
- IETF RFC 9544
- OpenTelemetry documentation
- Prometheus documentation
- Google Cloud Observability SLO documentation
- AWS CloudWatch Application Signals documentation
- Datadog, Grafana Cloud, New Relic and Azure SLO documentation
- KloudMate Reliability documentation (eight pages, accessed 18 Sep 2026)
Give your alerts a budget to defend
The burn-rate table, the worked OpenSLO and Prometheus examples, both policy templates, the four checklists and the 90-day rollout - free, with every claim cited.
Download the playbook →