The Stale Audit Figure Hiding in a 4 AM Restart Document

The planning document was four hours old when someone found the wrong paragraph near the bottom of it.

The document was ordinary and useful: a reference for restarting a handful of production systems safely, written so that whoever is on call at four in the morning doesn’t have to work everything out from scratch under pressure. It had a “known gaps” section listing what hadn’t been personally verified yet. One system had been checked directly. The other two hadn’t, so for those the document leaned on what we already knew: an audit figure from months earlier, and a prediction built on top of it. The prediction said one of the two likely carried the biggest backlog of pending work, so its first restart should be treated as the risky one.

A fact that was months old

That prediction went into the document as settled fact, because it read like one. It was a guess dressed up in an old number’s clothes. It didn’t feel like a guess while we were writing it, because the reasoning was “the audit said so.” Nobody asked whether the audit was still true by the time it mattered.

The correction

A reviewer looking over the same material caught it. That system had been restarted recently, not months ago. Rather than argue from memory, we checked the live system directly. The number came back at about six days, not the months-old figure the document had quoted. A full restart had already happened.

That flipped the picture the document had painted. The system we had written off as already handled was the outlier, sitting on weeks of accumulated backlog with nothing addressed. The one flagged as risky had already gone through a clean restart with nothing pending at all.

We rewrote the section the same day. The stale prediction came out, replaced by the verified number and a question nobody had asked before. These are systems someone else also has a hand in maintaining, and nothing on record said whether that recent restart was intentional or part of routine outside maintenance. That matters for deciding the right next move, so it went into the document as a question, not as a guess posing as an answer.

What went wrong

Nobody supplied bad information. The original audit was accurate at the moment it was taken. What went wrong was treating “this was true when measured” as the same thing as “this is true now,” and the gap between the two was months long. A number sitting in a document shows no timestamp for how stale it is allowed to get. It reads the same whether it was checked this morning or half a year ago, and the only way to tell the difference is to go check the actual system, not to reread the document more carefully.

The document is more useful now, and the reason has nothing to do with formatting. It says which numbers are current and says out loud what nobody knows yet. A gap admitted in writing is a smaller problem than a guess presented as fact, and the second kind is what puts someone in front of the wrong system at four in the morning, budgeting for a risk that has already moved somewhere else.

Before a number from an earlier audit goes into a runbook or plan, check when it was measured and re-check it against the live system.

dxdev LESSON · paste into your AI coding agent
LESSON: A written number carries no visible expiration date, so check it before it drives a real decision
SOURCE: dxdev.com/blog/the-number-i-wrote-down-was-already-wrong
WHAT HAPPENED: A maintenance reference document for a small set of production systems carried forward a months-old audit figure for one of them and used it to predict that system would be the riskiest one to restart first. A reviewer pointed out the underlying system had actually been restarted recently. Checking it directly instead of arguing from memory showed it had only been up a matter of days, meaning the entire risk prediction was backwards: the system flagged as safe was actually the one carrying the real backlog, and the one flagged as risky had already been fully restarted with nothing pending.
THE RULE: An old measurement copied into a new document carries no visible expiration date. It reads exactly as true as a number checked minutes ago. Before a number drives a real decision, especially one that names which of several similar things is the riskiest, re-verify it against the live system it describes rather than trusting the document that quoted it last.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any operational document carrying a specific number (a count, an age, a size) that traces back to a measurement more than a few weeks old, with no re-verify date attached.
  2. Any "known risks" or "known gaps" section that predicts which of several similar systems is the risky one, based on a number that wasn't re-checked when the document was written.
  3. Any document a team will actually plan a live action around that has never been re-verified against the current state of what it describes.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.