When the Map Burns with the Territory (Oct 2021 – Dec 2022)

The defining image of this window is Facebook engineers reportedly unable to badge into their own buildings because the outage had taken down the systems that controlled the doors. Incident after incident showed recovery tooling, communications, and even physical access welded to the infrastructure they were supposed to repair.

The incidents that defined the period

  • Facebook/Meta, October 4, 2021 — A routine maintenance command disconnected Facebook’s backbone; its DNS servers, by design, withdrew their BGP routes when they couldn’t reach the datacenters. Facebook, Instagram, and WhatsApp vanished from the internet for ~6 hours. Internal tools and remote access died too, forcing physical datacenter visits (engineering.fb.com).
  • Roblox, October 28–31, 2021 — A 73-hour outage from a subtle interaction between a Consul feature and BoltDB performance. The postmortem, co-published with HashiCorp months later, was praised for depth and for neither party hiding behind the other.
  • AWS us-east-1, December 7, 2021 — An automated scaling activity triggered a thundering herd on the internal network connecting AWS’s own services; monitoring and support tooling were among the casualties, slowing diagnosis (aws.amazon.com/message/12721). Two further December us-east-1 incidents made “why is everything in one region?” a CTO-level question.
  • Log4Shell, December 2021 — A logging library CVE that turned every Java shop’s December into an incident. The response was run like an outage and postmortem’d like one; SBOMs went from acronym to mandate.
  • Atlassian, April 2022 — A maintenance script given the wrong IDs permanently deleted ~400 customers’ cloud sites; restoration took up to two weeks because recovery was designed for whole-service rollback, not per-customer restore. The postmortem’s candor about that gap was the lesson.
  • Rogers, July 8, 2022 — A maintenance update removed a routing filter and the resulting BGP flood crashed Canada’s largest network — including 911 access and Interac payments — for ~a day. National reviews followed; reliability became telecom regulation.
  • Cloudflare, June 21, 2022 — A BGP change during a datacenter conversion took down 19 of their busiest locations; postmortem published same day.
  • UK heatwave, July 2022 — Google and Oracle cloud regions in London throttled by cooling failures: climate as a reliability factor.
  • Southwest Airlines, December 2022 — Crew-scheduling software collapsed under a winter storm; ~17,000 flights cancelled. The eventual reckoning (including a record fine) made “legacy system risk” a board agenda item.

What the postmortems reveal

1. Recovery must not depend on the thing being recovered. Facebook’s DNS, AWS’s monitoring, Atlassian’s restore tooling — each incident extended because the repair path ran through the failure. Out-of-band management networks, break-glass access, and offline runbooks became the era’s universal action item.

2. Deletion needs different engineering than failure. Atlassian could survive crashes fine; it couldn’t un-delete quickly. Soft-delete windows, per-tenant restore, and “recycle bin” semantics for infrastructure entered platform roadmaps.

3. The supply chain is part of your system. Log4Shell postmortems weren’t about a bug but about inventory: who could answer “where do we run log4j?” in hours instead of weeks.

4. Public infrastructure expectations arrived. Rogers and Southwest pulled regulators into the postmortem audience. Writeups started being drafted with governments, not just customers, in mind.

Practice and tooling shifts

  • Static stability and multi-region moved from AWS whitepaper language to actual funded projects after the December trilogy.
  • Dependency mapping tooling (service catalogs, Backstage adoption) surged — you can’t reason about blast radius you can’t see.
  • Learning-from-incidents culture matured: the Roblox/HashiCorp joint postmortem modeled vendor-customer co-analysis.

Takeaways that still hold

  1. Keep a way in that doesn’t depend on your network being up — and test that your badge readers, VPN, and runbooks survive your own outage.
  2. Rate-limit and stage removals (routes, filters, capacity, customers) even more carefully than additions.
  3. Practice per-tenant restore; whole-system rollback is the wrong grain for multi-tenant platforms.
  4. Maintain a dependency inventory you can query during an incident, not after.