---
title: "The Number I Wrote Down Was Already Wrong"
canonical: https://dxdev.com/blog/2026-07-26_the-number-i-wrote-down-was-already-wrong/
datePublished: 2026-07-26
---
I was building a maintenance reference document for a handful of production servers, the kind of thing meant to save the next person from re-deriving facts under pressure at four in the morning. Reboot procedure, expected downtime, what should come back on its own, what to check afterward. Routine work. The mistake I made was in a single paragraph near the bottom, and it took under four hours to get caught.

## A fact that was six months old

The document had a "known gaps" section, honest about what hadn't been verified yet. One of the three machines had been checked directly and walked through the whole procedure. The other two hadn't, so I wrote what I had: an audit figure from months earlier, an uptime count in the hundreds of days for one of them, and a prediction built on top of it. That machine, I wrote, likely carried the largest backlog of unapplied patches, so treat its first reboot as the high-stakes one.

It read like a fact because I wrote it like one. It was actually a guess wearing an old number's clothes, and I didn't flag it as a guess, because I didn't think of it as one. It was "the audit said so." I just hadn't asked whether the audit was still true.

## The correction

A reviewer looking at the same material caught it: that machine had been restarted recently. Not months ago, recently. Rather than argue from memory, I went and checked the live machine directly, over an existing database connection rather than a remote session, since the usual remote-check path didn't work between these particular machines. The real number came back at about six days of uptime, and the boot time and the service start time were close enough together to confirm it was a full restart, not a partial one.

That flipped the entire picture the "known gaps" section had painted. The machine I'd written off as already handled, the one I'd been treating as the safe baseline, was actually the outlier: it was the one sitting on weeks of uptime with a real backlog still staged. The machine I'd flagged as the risky one had, in fact, already been through a full restart and had nothing pending.

I rewrote the section the same day. The stale prediction came out, replaced by the verified number and an open question I hadn't thought to ask before: since these are managed machines, nothing recorded whether that recent restart was something we did or something the hosting side did as routine patching. If it's the latter, the right move for the other machine might be a support request timed to their maintenance window, not a hand-run reboot at an odd hour. I added that as a question worth raising, not as a fact, which is the distinction the whole mistake had been missing.

## What actually went wrong

Nobody fed me bad information. The audit was accurate when it was taken. What went wrong is that I treated "this was true when it was measured" as equivalent to "this is true now," and the gap between those two was months long. A number sitting in a document doesn't carry a visible timestamp for how stale it's allowed to get before someone stops trusting it. It reads the same whether it was checked this morning or six months ago, and the only way to tell the difference is to go check the thing itself, not to read the document more carefully.

The document is more useful now for a reason that has nothing to do with formatting or clarity. It says which numbers are current, and it says out loud, in the open question, exactly what nobody actually knows yet. A gap admitted in writing is a smaller problem than a guess presented as a settled fact. The second one is the one that gets someone standing in front of the wrong machine at four in the morning, budgeting for a risk that already moved somewhere else.