The Blameless Awakening (Jan 2013 – Mar 2014)

In early 2013, the public postmortem was still a novelty. Most companies treated outages as PR problems to be minimized, not learning opportunities to be shared. By the spring of 2014, that had visibly changed — and this 15-month window is where the modern postmortem culture took root.

The incidents that defined the period

  • Microsoft Azure, February 2013 — A worldwide Azure Storage outage caused by an expired SSL certificate. The lesson — certificate lifecycle management is an operational discipline, not a checkbox — still gets relearned every year.
  • Google, August 2013 — Google went dark for roughly 2–5 minutes, and global internet traffic reportedly dropped ~40%. The first mainstream glimpse of how concentrated the web had become.
  • Amazon.com, August 2013 — A ~30-minute outage of the retail site, widely used to popularize “downtime costs $X per minute” math in reliability business cases.
  • NASDAQ “Flash Freeze,” August 2013 — A three-hour trading halt traced to a software flaw in the Securities Information Processor, showing that finance’s bespoke infrastructure had the same failure modes as web systems.
  • HealthCare.gov, October 2013 — Not a cloud outage but the era’s defining systems failure: a big-bang launch with no load testing, no incremental rollout, and no operational ownership. Its rescue by a small team of web-industry engineers seeded what later became the US Digital Service — and became the canonical argument for DevOps practices in government and enterprise.

What the postmortems reveal

1. “Blameless” went from Etsy blog post to industry norm. John Allspaw’s writing on blameless postmortems and Etsy’s open-sourced Morgue tool (their internal postmortem tracker) gave teams both the philosophy and the software. The core idea — engineers closest to the failure have the most information, and punishing them destroys that information — started appearing in conference talks everywhere.

2. Root cause was becoming plural. The best 2013-era postmortems stopped saying “the root cause was X” and started describing contributing factors: an expired cert and no expiry monitoring and a deploy process that couldn’t roll back quickly. Richard Cook’s How Complex Systems Fail circulated widely.

3. Chaos engineering left the lab. Netflix’s Simian Army (Chaos Monkey had been open-sourced in 2012) proved you could schedule your failures. Their public writeups of surviving AWS instance and zone failures were effectively preemptive postmortems.

Practice and tooling shifts

  • ChatOps emerged: GitHub’s Hubot popularized running deploys and diagnostics from chat, which meant incident timelines started writing themselves.
  • On-call got a product category: PagerDuty and VictorOps turned paging from homegrown cron scripts into workflow software.
  • Continuous delivery as a reliability practice: smaller, more frequent deploys were increasingly justified in postmortems — big-bang releases kept showing up as contributing factors (HealthCare.gov being exhibit A).

Takeaways that still hold

  1. Certificates, quotas, and licenses expire on schedule; your monitoring should know the schedule before the outage does.
  2. A postmortem that names a person has failed; one that names a missing guardrail has succeeded.
  3. If you can’t launch incrementally, you’re choosing to discover all your failure modes on the same day.