The Outage That Didn't Happen

The highest-leverage engineering work leaves no evidence it happened. A note on why prevention is invisible, why that makes it fragile, and why the fleet makes it the whole job.

By Jason Waldrip, with Claude Opus 4.8 August 1, 2026 08:47

The best call I made last quarter has no artifact.

There’s no incident channel for it. No postmortem doc, no five-whys, no timeline with timestamps and a blameless retro. Nobody got paged at 2am. The dashboard stayed green the whole time. From the outside it looks like a week where nothing happened, because that’s exactly what happened: nothing. A failure that would have fired didn’t, because the shape of the system made it impossible. And the reward for that is that no one will ever know it was there.

Sit with that for a second, because it’s the whole problem. The work that saves you the most is the work that leaves no evidence it was done.

the ledger only records what breaks

Think about how you actually find out an engineer is good. You see the fire they put out. The gnarly bug they chased at midnight, the migration they rescued, the incident they commanded while everyone else refreshed the status page. Firefighting is legible. It has a start and an end, a villain and a hero, a thread full of praise emoji when it’s over. It photographs well.

Prevention photographs like a blank wall. The person who noticed the migration would lock the table under load and rewrote it before it ever shipped produced the same visible outcome as the person who did nothing: a quiet Tuesday. One of them saved the company a Saturday. You can’t tell which from the outside, and neither can their manager at review time.

Richard Cook made this point better than I can in How Complex Systems Fail: the reason a complex system runs at all is that people are continuously, invisibly steering it away from the edge. When they succeed, the system just keeps working, and the success is silent. We only see the system when it breaks, so we systematically mistake the absence of failure for the absence of risk. The safest operators generate the least evidence that they’re doing anything.

So the ledger is rigged. It records outages, not the ones you designed out. It logs the bug that shipped, never the one that died in review. And when the budget gets tight and someone asks what work is safe to cut, prevention is first on the block every time, because on paper it costs money and produces nothing. You are cutting the quiet Tuesdays. You just won’t find out until a Saturday.

the failures I’m proudest of are the ones you can’t see

The stories I actually tell about my own work are the loud ones. Brandfolder crashing on a memory leak when I walked in, and stopping the bleeding before anything else. Ruby falling over generating multi-gigabyte zip files, so we built that one pipeline in Go and it just stopped being a problem. Those are good stories because you can see the before and after. Something was broken, then it wasn’t.

But the decisions I’d actually defend hardest are the ones with no before-and-after to point at. At GigSmart I chose Elixir for the marketplace backend, and the reason was prevention. A real-time marketplace is a concurrency problem wearing a product costume, and I wanted fault isolation to be a property of the substrate, not a thing we remembered to bolt on later under load. Every process that can crash without taking its neighbors down is an incident that never gets written up. There’s no postmortem for the cascading failure that couldn’t cascade. That decision paid out every single day for years, silently, and it will never show up in a war story because nothing ever went to war.

Same shape at CommercialTribe. The work that mattered most wasn’t a feature. It was collapsing a release cadence from weeks to hours, moving to GCP and Kubernetes because that was the cheapest path to stability at our actual load. Weeks-to-hours reads like a speed win, and it is, but the deeper win is that a team shipping in hours learns from reality constantly while a team shipping in weeks is guessing. Every bad guess you don’t ship is a fire you don’t fight. You can’t count them. They’re not there.

prevention has no postmortem

Here’s the phrase I keep coming back to. Prevention has no postmortem. The best possible outcome of good judgment is a non-event, and a non-event generates no document, no credit, no story. Which means if you only reward what’s visible, you are training your best people to stop preventing and start firefighting, because the fire is where the recognition lives. You will get exactly the behavior you measure, and you are measuring the smoke.

The fix isn’t to stop firefighting. Fires happen, and someone has to walk into them. The fix is to make prevention legible on purpose, because it won’t make itself legible. When I run a fractional engagement now, the retainer is flat and it’s measured on two things: what shipped, and what got prevented. That second half is the hard half, and it’s the half most orgs never write down. You have to say the near-miss out loud. The bug that got caught in review, the design that changed before it went out, the load pattern you saw coming and built for. Name it, or it evaporates, and the person who saw it gets nothing while the person who cleaned up the version that shipped gets a bonus.

Writing the near-miss down is doing for prevention what a postmortem does for failure. It turns invisible judgment into a thing the team can see, learn from, and value.

why this is the whole job now

I’ve written before that volume is free now. A fleet of agents will generate more code, more migrations, more config, more plausible-looking pull requests than any team could produce by hand a year ago. Generation stopped being the bottleneck. And when generation gets that cheap, the entire value of the person in the loop collapses onto one thing: catching the bad output before it ships. That is prevention. That’s the whole game.

An agent will happily write the migration that locks the table. It’ll wire up the flow with no idempotency and no retry. It’ll produce something that passes its own tests and takes prod down at 3x traffic, and it’ll do it fast and cheerfully and at scale. The judgment that says “not that one, here’s why” before it merges is the scarce thing. It’s also, by its nature, invisible. Nobody sees the outage the review prevented. You have to decide that catching it counts, and then you have to build the guardrails, the CI, the review, the types, that turn one person’s judgment into something the whole fleet runs inside of.

Multiply that judgment across a fleet and you get real leverage. Skip it and you’ve built a machine that generates Saturdays at scale.

So here’s the question I’d leave you with, the one I ask myself at review time. Who on your team had the quietest quarter, and did you check whether it was quiet because they weren’t doing much, or quiet because they were the reason nothing broke? The answer to that is worth more than any incident report you’ll read this year. It just won’t come with one attached.