Last reviewed on 4 May 2026.
Analytical readings of publicly-disclosed API and infrastructure incidents, framed through an API-design lens. Each piece pairs with the official postmortem from the affected company.
Public postmortems from the major API and infrastructure providers are some of the most useful documents in the field. They describe specific failures with specific causes, in concrete language. The official postmortems do an excellent job of saying what happened. They typically don't have space to draw out the broader lessons — what design decisions made the failure possible, how the same patterns surface in other systems, what other API providers should change as a result.
This series fills that gap. Each piece is a reading of a specific public incident: a summary of what the official postmortem says, followed by an analysis of what the incident illustrates about API and system design. The aim is the lesson, not the gossip; we attribute everything we claim about each incident to the public source and don't speculate about details the affected company didn't disclose.
Not an outage but an architectural choice worth reading as carefully: how Stripe handles API versioning, why their approach has aged better than alternatives, and what other API providers should learn from it.
A multi-hour outage triggered by automated capacity scaling that interacted badly with the network monitoring system. A case study in control-plane vs data-plane design and the danger of automated remediation that amplifies its own failures.
A two-day control-plane outage triggered by a power failure at a single data center. A case study in the limits of regional redundancy, the importance of exercising failover paths, and what makes a postmortem credible.
Not every public postmortem makes a good reading. We're looking for ones that satisfy several criteria:
Most pieces in this series will be 2,000–3,000 words. They're paired with the appropriate reference pages on the rest of the site so readers can dig deeper into the principles each incident illustrates.
The backlog of incidents and architectural decisions worth reading carefully is long. Likely upcoming pieces:
If there's a public postmortem you'd like to see read carefully, the contact page has the address.
For the patterns and references that the postmortem analyses lean on, see the reference. For the long-form articles that go deeper on specific subtopics, see the rest of the blog. For the curated reading list of foundational pieces in API design, see the canon.