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

## A fact that was six months old

The document had a "known gaps" section, open 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 we wrote what we had: an [audit figure from months earlier](/everyday-ai/the-old-number-that-still-looked-like-a-fact/), an uptime count in the hundreds of days for one of them, and a prediction built on top of it. That machine, we wrote, likely carried the largest backlog of unapplied patches, so its first reboot was the high-stakes one.

It read like a fact because we wrote it like one. It was a guess wearing an old number's clothes. We never flagged it as a guess because we didn't see it as one. To us it was "the audit said so," and we 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. Rather than argue from memory, we checked the live machine directly. The usual remote-check path didn't work between these particular machines, so we went over an existing database connection instead. The real number came back at about six days of uptime. The boot time and the service start time were close enough together to confirm a full restart.

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

We rewrote the section the same day. The stale prediction came out. In its place went the verified number and an open question we hadn't thought to ask before. These are managed machines, and nothing recorded whether that recent restart was something we did or something the hosting side did as routine patching. If it was the hosting side, the right move for the other machine might be a support request timed to their maintenance window, with no hand-run reboot at an odd hour. We added that as a question worth raising and left it out of the facts, which is the distinction the original paragraph had been missing.

## What actually went wrong

Nobody fed us bad information. The audit was accurate when it was taken. We treated "this was true when it was measured" as equivalent to "this is true now," and the gap between the two was months long. A number sitting in a document carries no visible timestamp for how stale it's allowed to get. 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. Reading the document more carefully won't do it.

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

Any figure in an operations document should come with a date for when it was last measured, and it should be re-checked against the live system before anyone acts on it. Mark anything unverified as a question, not a fact.