Site
Changelog and errata
What changed on SREference and when. Corrections to anything that was published wrong are listed first, as errata, with what was wrong and what it says now. Each guide also shows the date it was last reviewed.
Errata
- : The postmortem template’s example detection action item said to page when the checkout SLO burns faster than 14.4×. The template’s sample SLO is over 28 days, where the 2%-in-1-hour page is 13.44×; 14.4× is the figure for a 30-day window. The action item now says 13.44×, computed from the 28-day window.
- : The postmortem template’s example detection action item was “Alert on queue depth > 10,000 for 5 min”, a cause-based alert, which contradicted the site’s advice to page on symptoms. It is now a checkout SLO burn-rate page, and the action-item advice says new detection items should alert on what users experience and retire stale alerts, citing Observability Engineering, 2nd edition (2026).
- : The glossary defined observability as understanding a system from its outputs, “typically metrics, logs and traces”. That presented one contested model as the norm; the entry now says from the telemetry it emits and notes both the “three pillars” view and the wide structured events view. New entries: cardinality, dimensionality, OpenTelemetry, sampling, span, structured event and trace.
- : The SLI types table had one “Throughput / coverage” row, defined as a record processed within the expected time. Those are two SLIs, and the definition described freshness. The table now has Coverage (valid inputs processed successfully) and Throughput (time in which the processing rate stays above a threshold), as in the second edition of Google’s SRE book.
- : The PRR guide said Google uses a production readiness review as the prerequisite for SRE taking over a service. That was the first edition’s model; the second edition (2026) says Google SRE has moved away from strict PRRs and retired its engagement tiers in 2025, keeping full reviews for complex or risky launches and relying on standard platforms, lightweight reviews and teams’ own launch reviews. The guide now says so and presents the six phases as the first edition’s onboarding model.
- : The MTTR guide said the SRE book “still” calls MTTR the most relevant measure of emergency response, and that it reads the R as repair. Both are true only of the first edition. The second edition reads MTTR as mean time to resolution, alongside mean time to mitigation, says the averages mislead, and suggests measuring coordination cost instead; the guide now gives both editions and adds coordination cost to what to measure.
- : On-call basics said Google’s SRE book gives a bare minimum of five engineers per site for a two-site rotation. The book gives a reasonable minimum of six per site; five is the SRE Workbook’s bare minimum. The guide now gives both with their sources, and says the Workbook’s extra engineer per site protects against people leaving the rotation, not holidays and illness.
- : Glossary corrections. Chaos engineering said it aims to find weaknesses rather than confirm resilience; it does both, building confidence when the system withstands an experiment. MTTR was described as a rough trend; Google’s Incident Metrics in SRE finds it unsuitable for trends, so it now says not to use MTTR alone for trends or targets. The incident commander no longer always avoids hands-on work, and the entries for nines, toil, percentiles, rollback, feature flags, error budget policy, failover and severity are qualified to match their sources and guides.
- : About said the site has no forms that submit data; with JavaScript turned off, the calculator forms send their values to the server in the URL, and About now says so. It also now mentions the saved theme preference and describes Fathom only when analytics are enabled. The home page’s 14.4× and 50h figures now state that they are the Workbook’s starting threshold over both 1-hour and 5-minute windows, and assume a constant burn rate from an unspent budget.
Changes
| Date | Change |
|---|---|
| Erratum. The postmortem template’s example detection action item said to page when the checkout SLO burns faster than 14.4×. The template’s sample SLO is over 28 days, where the 2%-in-1-hour page is 13.44×; 14.4× is the figure for a 30-day window. The action item now says 13.44×, computed from the 28-day window. Blameless postmortem template | |
| Clarification: the error budget policy’s graduated table was headed “Budget remaining” (more than 50%, 25–50%, 0–25%, exhausted), while the opening thresholds and the SLO cheatsheet count budget spent (50%, 75%, 100%). The old bands were correct; the table now uses budget spent too (under 50%, 50% to under 75%, 75% to under 100%, 100% or more), with the same response in each band. The worked example reports 76% spent, in the 75% to under 100% band, where it said 24% remaining. The budget 80% drill’s notes say 75% or more spent. The template’s postmortem trigger asks for an action item addressing the incident’s main contributing factors, not “the root cause”. Error budget policy · Drill | |
| Wording changes: the error budget policy now says a single cliff at 100% changes nothing until the freeze; the availability table explains that request-based availability weights failures by the requests they hit; the calculator describes the Workbook’s burn-rate alerts as starting points; and “utilisation” is spelt in British English in the golden signals guide and the glossary. Availability table · Error budget and burn-rate calculator · Error budget policy · Golden signals, RED and USE · SRE glossary | |
| The opening paragraphs of four guides now answer the page’s main question first: what MTTR, MTTD and MTBF mean and how MTBF and MTTR give long-run availability; the 25% on-call cap, two incidents per 12-hour shift and minimum rotation size; what SEV1 and SEV4 mean in the starting-point matrix; and what canarying is. No figures were added; each comes from the page itself. MTTR, MTTD and MTBF · On-call basics · Incident severity levels · Safe rollouts and canarying | |
| Erratum. The postmortem template’s example detection action item was “Alert on queue depth > 10,000 for 5 min”, a cause-based alert, which contradicted the site’s advice to page on symptoms. It is now a checkout SLO burn-rate page, and the action-item advice says new detection items should alert on what users experience and retire stale alerts, citing Observability Engineering, 2nd edition (2026). Blameless postmortem template | |
| Erratum. The glossary defined observability as understanding a system from its outputs, “typically metrics, logs and traces”. That presented one contested model as the norm; the entry now says from the telemetry it emits and notes both the “three pillars” view and the wide structured events view. New entries: cardinality, dimensionality, OpenTelemetry, sampling, span, structured event and trace. SRE glossary | |
| The latency percentiles guide now shows, from Observability Engineering, 2nd edition (2026), why counting requests beats judging whole minutes by their p95, and adds a section on percentiles from sampled data, which must be weighted by sample rate. The SLI guide adds the same point, a caveat that synthetic probes catch full outages sooner than partial ones, and guidance on window length. Latency percentiles · SLI vs SLO vs SLA | |
| The burn-rate guide’s “Where sources differ” box adds the predictive burn alerts in Observability Engineering, 2nd edition (2026) as an alternative to the Workbook’s rules, with the burn rate they correspond to. The alerting guide adds that a symptom alert says what is wrong but not why, a warning about alerts added after each incident, and the book’s opposing view on learned thresholds and alert grouping. Multiwindow, multi-burn-rate alerting · Alerting principles | |
| The PRR checklist adds structured events with build, endpoint and customer fields and trace propagation. The rollout guide adds a “Where sources differ” box on deploy-time windows and rolling back first, and recording flag state per request. The runbook template sets out the book’s case against detailed runbooks. All cite Observability Engineering, 2nd edition (2026). Production readiness review checklist · Safe rollouts and canarying · Runbook template | |
| Erratum. The SLI types table had one “Throughput / coverage” row, defined as a record processed within the expected time. Those are two SLIs, and the definition described freshness. The table now has Coverage (valid inputs processed successfully) and Throughput (time in which the processing rate stays above a threshold), as in the second edition of Google’s SRE book. SLI vs SLO vs SLA | |
| Erratum. The PRR guide said Google uses a production readiness review as the prerequisite for SRE taking over a service. That was the first edition’s model; the second edition (2026) says Google SRE has moved away from strict PRRs and retired its engagement tiers in 2025, keeping full reviews for complex or risky launches and relying on standard platforms, lightweight reviews and teams’ own launch reviews. The guide now says so and presents the six phases as the first edition’s onboarding model. Production readiness review checklist | |
| Erratum. The MTTR guide said the SRE book “still” calls MTTR the most relevant measure of emergency response, and that it reads the R as repair. Both are true only of the first edition. The second edition reads MTTR as mean time to resolution, alongside mean time to mitigation, says the averages mislead, and suggests measuring coordination cost instead; the guide now gives both editions and adds coordination cost to what to measure. MTTR, MTTD and MTBF | |
| The incident roles guide now distinguishes the editions of Google’s SRE book. The first edition’s four roles, including a planning lead, and its view that keeping the incident document is the incident commander’s most important job are labelled as such. The second edition names three primary roles (incident commander, communications lead, operations lead), gives documenting the incident’s state to the communications lead, and describes an internal and external communications split at Google as well as at PagerDuty. The planning lead stays as an option. Incident roles and communication | |
| For low-traffic services the burn-rate guide now leads with the binomial test that the second edition of Google’s SRE book calls standard for its SLO alerts: page when failures exceed N × P + Z × √(N × P × (1 − P)), so the bar rises as traffic falls. The worked example, the PromQL and the cheatsheet use it, computed and tested in the site’s SLO code against the book’s own figures. A minimum request count is now described as the cruder option. Multiwindow, multi-burn-rate alerting · SLO design cheatsheet | |
| Updated for the second edition of Google’s SRE book: alerting principles notes that it moves beyond “alert on symptoms” with learned baselines and keeps quota and resource cause alerts; on-call gives its four to six hours per incident alongside the first edition’s 12-hour shift; the golden signals are described as a starting point for investigation; and the glossary defines incident and outage as the book does and adds MTTM and RWO. Alerting principles · On-call basics · Golden signals, RED and USE · SRE glossary | |
| The response flow now separates mitigation (user impact stopped or reduced enough to end the emergency) from resolution (the system is stable again), and adds triage, following the incident lifecycle in the second edition of Google’s SRE book. Incident severity levels | |
| Added a section on CAST, the systems-based postmortem method in the second edition of Google’s SRE book, and its view that incidents come from a design that does not constrain unsafe behaviour rather than from one root cause; also notes its independent postmortem lead and outcome bias. Learning from incidents | |
| Added the restore window objective (RWO), the third data recovery objective in the second edition of Google’s SRE book: how far back you must be able to restore, set between business needs, which include outlasting undetected corruption, and data retention and deletion obligations. RTO vs RPO | |
| Added material from the second edition of Google’s SRE book: when toil is acceptable and its warning signs; judging a canary on its callers’ errors for requests that reached the new version; and, in the error budget policy, that users depend on the reliability they actually get, and how to bound a freeze after a large overspend. Toil · Safe rollouts and canarying · Error budget policy | |
| Checked every guide against the second edition of Google’s SRE book (2026). Citations of the first edition are now labelled “1st ed.”, and pages cite the second edition by chapter and section where it applies. | |
| Added an SLO design cheatsheet: a copyable SLO spec template, SLI types, how to set a target, the error budget per target, windows and burn-rate alert thresholds, and error budget policy steps, on one sheet with A4 and US Letter PDFs. SLO design cheatsheet | |
| Added three printable tabletop discussion drills, a lighter take on the SRE book’s disaster role playing (“Wheel of Misfortune”), each on its own page with facilitator notes and A4 and US Letter PDFs: should this page someone, 80% of the error budget spent with 10 days left, and writing the first incident update. Every answer is calculated by the site’s tested SLO code. Drill · Drill · Drill | |
| Added a guide to learning from incidents beyond root cause: hindsight bias, facilitated learning reviews, questions to ask, a “where sources differ” box on whether every review needs action items, and a worked example of choosing which incident to study by error budget spent. Learning from incidents | |
| Added a production readiness review guide: what a PRR covers, how to run one, a copyable checklist, and a worked example checking an SLO against its dependencies and sizing capacity for N + 2. Production readiness review checklist | |
| Added a guide to safe rollouts and canarying: canary versus control, stage sizes and bake times, automatic rollback, two-phase deployments for data changes, configuration and feature flags, a rollout plan template and a worked example of what a canary saves. Safe rollouts and canarying | |
| Added a guide to overload and load shedding: goodput, shedding by criticality, bounded queues, client-side adaptive throttling, graceful degradation, how shedding interacts with autoscaling and load balancing, and an overload runbook, with a worked example. Overload and load shedding | |
| Added a guide to timeouts, retries and backoff: choosing a timeout from a dependency’s latency, deadline propagation, retry budgets, full-jitter backoff and retry storms, with a starting retry policy and a worked example. Timeouts, retries and backoff | |
| The burn-rate guide now includes PromQL for availability and latency SLIs, the current burn rate and the share of the 30-day budget left, with a worked reading of the numbers. Its alert rules take their thresholds from the site’s tested SLO code, and the recorded error ratio now reads 0 rather than no data while no 5xx series exists. Multiwindow, multi-burn-rate alerting | |
| Erratum. On-call basics said Google’s SRE book gives a bare minimum of five engineers per site for a two-site rotation. The book gives a reasonable minimum of six per site; five is the SRE Workbook’s bare minimum. The guide now gives both with their sources, and says the Workbook’s extra engineer per site protects against people leaving the rotation, not holidays and illness. On-call basics | |
| Erratum. Glossary corrections. Chaos engineering said it aims to find weaknesses rather than confirm resilience; it does both, building confidence when the system withstands an experiment. MTTR was described as a rough trend; Google’s Incident Metrics in SRE finds it unsuitable for trends, so it now says not to use MTTR alone for trends or targets. The incident commander no longer always avoids hands-on work, and the entries for nines, toil, percentiles, rollback, feature flags, error budget policy, failover and severity are qualified to match their sources and guides. SRE glossary | |
| Erratum. About said the site has no forms that submit data; with JavaScript turned off, the calculator forms send their values to the server in the URL, and About now says so. It also now mentions the saved theme preference and describes Fathom only when analytics are enabled. The home page’s 14.4× and 50h figures now state that they are the Workbook’s starting threshold over both 1-hour and 5-minute windows, and assume a constant burn rate from an unspent budget. | |
| The on-call cheatsheet now prints on one sheet, and has a print button and ready-made PDFs for A4 and US Letter. On-call cheatsheet | |
| Added a worked numeric example to each guide that lacked one, with every number computed by the site’s tested SLO code. Error budget policy · Incident severity levels · Incident roles and communication · Blameless postmortem template · Runbook template · On-call basics · Alerting principles · Toil · Golden signals, RED and USE | |
| Added “Where sources differ” boxes: severity scales (PagerDuty and Atlassian), the meaning and use of MTTR (Google’s SRE book, Davidovič and DORA), root cause (Google’s books and Richard Cook) and burn-rate alert thresholds (the SRE Workbook, Sloth and Pyrra). Incident severity levels · MTTR, MTTD and MTBF · Blameless postmortem template · Multiwindow, multi-burn-rate alerting | |
| Added the on-call cheatsheet. Redesigned the glossary with a term index and a filter. On-call cheatsheet · SRE glossary | |
| Added guides on MTTR, MTTD and MTBF; latency percentiles; incident roles and communication; and alerting principles. MTTR, MTTD and MTBF · Latency percentiles · Incident roles and communication · Alerting principles | |
| Added the runbook template and the RTO vs RPO guide, SLO examples by service type, and calculated diagrams in the burn-rate, RTO and SLO guides. Runbook template · RTO vs RPO · SLI vs SLO vs SLA · Multiwindow, multi-burn-rate alerting | |
| Launched with the availability table, the error budget calculator, eight guides and the glossary. |
Changes are dated by when they were published. Minor wording and layout changes that don’t alter what a page says are not listed.