Ask any veteran operator about their worst outages and a pattern emerges: most of them were self-inflicted. Not an attacker, not a hardware failure, not an act of God — a change. A config pushed, an update applied, a "quick fix" that wasn't. The infrastructure was fine until someone, often the person telling the story, changed it.

This isn't a competence problem. The people who cause change-induced outages are frequently the most capable, because they're the ones trusted to make changes. It's a discipline problem, and the fix is almost insultingly simple: a short checklist, run before every change, especially the ones you're certain are trivial. The trivial ones cause the most outages precisely because they bypass the caution the scary ones trigger.

The checklist

Five questions. Run them before you touch anything. They take five minutes and they are the cheapest insurance in operations.

1. What exactly am I changing, and what does it touch? Name the change precisely, and trace its blast radius. Not "updating the firewall" but "changing rule 47, which governs traffic between the app tier and the database." What depends on the thing you're changing? What breaks if this goes wrong? If you can't answer what it touches, you don't understand the change well enough to make it safely.

2. How do I undo it? Before you make the change, know exactly how to reverse it. Not vaguely — specifically. The config backup is saved and you've confirmed it's valid. The snapshot is taken. The previous firmware is on hand. The rollback command is written down. "I'll figure out how to undo it if it breaks" is how a five-minute change becomes a five-hour outage, because you're now debugging the rollback under pressure instead of having it ready.

3. How will I know if it worked — and how will I know if it broke something else? Define success before you start. What specifically proves the change did what you wanted? And just as important: what proves it didn't break something adjacent? The change that fixes the thing you were looking at while silently breaking the thing you weren't is the classic. Know what "still healthy" looks like for the neighbors, and check it.

4. Is now the right time? Not during the business-critical window. Not Friday at 5 p.m. when a problem means your weekend. Not when the one person who understands this system is unreachable. Not when you're rushed or tired. The right time for a change is when you have the attention to do it carefully and the runway to fix it if it goes wrong. "Now" is rarely the honest answer when you ask the question.

5. Who needs to know? Someone should know a change is happening, even on a small team — so that if the monitoring lights up, it's immediately connected to the change instead of investigated as a mystery. And so that if you're the one who goes down with the change, someone else knows what was touched. A change nobody knew about is an outage that takes twice as long to diagnose.

Why the trivial changes are the dangerous ones

The large, scary changes get the care — the maintenance window, the rollback plan, the extra pair of eyes — because they look dangerous. It's the small ones that bite: the "quick" config tweak, the "minor" update, the "I've done this a hundred times" routine. They skip the checklist because they feel too small to warrant it. And then one of them touches something nobody traced, with no rollback ready, at the worst possible time, and takes down production.

The discipline is to run the checklist regardless of how small the change feels. The five minutes cost the same whether the change is trivial or terrifying. The outage costs far more than five minutes, every time.

Making it a reflex

The checklist only works if it's automatic — run every time, not just when you remember to be careful. A few ways to make it stick:

  • Keep it visible. Taped to the monitor, pinned in the change channel, in the runbook template. Friction against skipping it.
  • Make it social. On a team, a lightweight "change announced + checklist confirmed" norm means the list gets run because someone would notice if it didn't.
  • Treat skipping it as the error, even when nothing broke. The change that went fine without the checklist wasn't a success — it was a gamble that happened to pay off. Reward the discipline, not the luck.

The operators who keep the lights on aren't the ones who never make mistakes. They're the ones who caught the mistake in the five minutes before they shipped it. The checklist is where that catching happens. It's boring, it's repetitive, and it's the single highest-leverage habit in the whole discipline. Run it every time — especially when you're sure you don't need to.