Guides built on public release incident reports

Each guide works through public reports already cited on the site's incident pages; no guide adds examples of its own.

8 guides

All guides

  • Canary and feature flag rollout checks drawn from public incident reports Canary and progressive delivery checks (a small share of traffic runs the new version with automated metric comparison) catch regressions visible in traffic metrics, memory growth and error rate rises. The canary class cannot catch faults in traffic the canary never receives, batch jobs or scheduled tasks. Five published incidents show canary and feature flag rollouts letting faults through, and each check below traces to one of 8 cited reports.
  • How the playbook is built from public incident reports Every incident page follows the same 13 sections and is published only when at least two independent public reports from distinct organisations are accepted, with at least one published in the last 5 years. Each candidate report passes a mechanical quote check and then a definition-fit review before it counts. Of 346 candidate reports recorded, 189 are accepted, 157 are rejected and none await review, and 26 of 84 incident pages are withheld.
  • How to write a release post-mortem that can serve as public evidence A release post-mortem (a written review of an incident: timeline, cause, impact and follow-up actions) serves as primary evidence when it names the organisation, the date, the change, the time of the change, the time of detection, the impact and the tests involved. Of 163 accepted primary and secondary reports on the site's published incident pages, 26 state both the change time and the detection time. The site's verifier rejected 157 candidate reports, and 126 of those rejections were for not matching the incident definition.
  • Migration safety checks before a release, drawn from public incident reports Migration tests (migrations run against a production-shaped copy with timing and rollback checks) catch failing or slow migrations, missing indexes, locks and irreversible changes. Migration tests cannot catch faults in the application code paths that read the new schema. The 10 cited reports below show where migrations failed in production and which checks their own follow-ups name.
  • How to set regression scope from published release incident history Add an incident type to the regression scope in order of its impact grade, then its likelihood grade, and write each case around the data state named in the incident's caught-by limitation. Of the 58 published incident types, 11 carry impact high and none carries likelihood high. Of 158 caught-by entries, 17 are cited from public reports and 141 carry the by design analysis label.
  • Release checklist for mobile apps, built from published mobile incidents Before a mobile release, launch the exact submitted binary on the oldest supported OS version, ship it as a halting-capable phased rollout, and prepare a workaround for each core flow. In 5 accepted public reports on store releases, recovery came from a fixed version that passed store review, not from a rollback. 2 other mobile release incident types stay withheld because fewer than 2 independent public reports were accepted for each.
  • Release checklist for payment products, built from published payment incidents Before a payment release, run checkout end to end for every customer segment, compute tax from the current rate table, and run each scheduled billing job once in staging. These checks come from 3 of the 4 published incidents in the payments and billing group, each graded likelihood low and impact high on 2 public reports. The 5 other incident types in that group stay withheld because fewer than 2 independent public reports were accepted for each.
  • How to read the risk map before choosing a tool or a contractor Each incident page grades likelihood from the count of public reports in the last 5 years and grades impact from the impact class those reports state. The caught-by table names 1 to 3 test classes, each with one limitation sentence and a basis label. The What catches this block then lists, in alphabetical order, only the tools and providers whose own documentation or site names those classes.

Questions

Why did tests not catch the bug?

Each incident page states, for every test class that catches it, the one limitation that applies there; each class also has a fixed list of what it cannot catch.

How do you check whether a tool or a provider documents a test class?

Open the test class page or the incident page: the catalogue block lists only tools and providers whose own documentation or site names that class, with the source URL and verification date.