Yesterday's piece ended with a caveat I did not resolve: drills test a snapshot. You run them in Q1 and Q3, and between those two afternoons, reality keeps moving. The drill tells you the state of the system on the day you ran it. It says nothing about the eleven weeks after.
That gap has a name and it deserves its own layer. Call it drift.
Drift is not failure
The instinct is to treat drift as a symptom of neglect — something a disciplined team would not have. That instinct is wrong, and it causes people to buy the wrong fix.
Drift is the default behavior of any system with more than one person and more than one week of history. The system changes because the business needs it to change. The description changes only when someone remembers, has time, and believes the description matters. Those three conditions rarely line up. So the description loses, every time, and not because anyone was careless.
There are three ways it happens.
Change without a doc change. A port moves. A queue is renamed. A service that used to be single-tenant becomes multi-tenant because a customer asked. Nobody updates the runbook, because the runbook was not in the path of the work. This is the ordinary case, and it accounts for most drift.
A doc change without a reality change. Someone updates the runbook to describe the system they intend to build, or the system they believe exists. Now the documentation is not stale — it is confidently wrong, which is worse. A stale doc makes you go look. A wrong doc makes you stop looking.
People change. The person who knew why the retry limit is three leaves, and the number stays. This is the fastest form of drift, because it removes the only index into the system's undocumented decisions. When a company cuts a quarter of its staff — or buys out a quarter of them — it is not losing headcount. It is losing the oral tradition.
The asymmetry nobody prices
There was a study on Hacker News this week with a title that is essentially the whole argument: reviewers rarely talk about reliability, owners bring it up twice as often. Outsiders rate a product on features. The people who run it rate it on whether it stays up.
That gap is not a bias to be corrected. It is structural information. The owner's estimate includes things the reviewer cannot see, and the most important of those things is drift: the accumulating distance between what the system is documented to be and what it is at 3 a.m.
Which means the buyer doing due diligence is systematically reading a different document than the seller. The seller is answering questions about capability. The seller's own engineers, if asked privately, would answer questions about decay. Nobody asks them, because the questionnaire was written by someone who has never been on call.
The Tailscale case is not about Tailscale
This week Tailscale published an investigation update on vulnerabilities in Tailscale SSH. Most of the findings were privilege escalation: someone already authorized to connect could, under some configurations, act beyond the permissions of their configured local user, potentially gaining elevated privileges. Serious, handled seriously, patch targeted within days.
Read the "what customers can do now" section, though. The recommended interim mitigations are not patches. They are configuration changes: review your SSH access policies, make sure access is limited to users and devices that need it, and disable SSH forwarding if you do not need it by setting TS_SSH_DISABLE_FORWARDING=1.
That last line is the entire lesson. A vendor can ship a perfect fix, and your exposure can remain, because your exposure was never only in their code. It was in a forwarding flag someone enabled in 2024 for a reason that no longer applies, in a policy that grants a group access because the group had three people then and has nineteen now.
The patch addresses the vulnerability. It does not address the drift. The drift is in the grants.
Every team that reads that advisory will patch within a week and almost none will re-derive who should have SSH access at all. The advisory tells them what to do about Tailscale. It cannot tell them what to do about themselves.
The one number worth tracking
If drift is the default, the useful question is not "how do we prevent it" — you don't — but "what do we measure so we notice."
Most continuity metrics fail because they measure the wrong object. "Do we have a runbook" is a yes/no about an artifact. "Is the runbook accurate" is unanswerable without doing the work of checking.
The metric that works is a count with a date on it: the number of people who can do X without asking anyone. Not the number authorized. The number who actually can, verified this quarter, by watching them do it.
Pick three X's that would hurt: restore the primary database, rotate the root credential, deploy the money path. Count. Write the number down with today's date. Next quarter, count again.
Two things happen. First, the number is usually lower than anyone on the team expects, and it is lower for a specific, fixable reason — a step that depends on one person's memory, a permission that was never granted to the backup. Second, and more valuable: the act of counting produces the doc-reality diff as a byproduct, because you cannot watch someone follow the runbook without noticing where the runbook lies.
Date every claim
The cheapest durable practice I know is this: any factual claim about your system carries the date it was last verified. Not the date it was written. The date someone checked.
"Our backups are tested" is a belief. "Backups restore successfully to a clean environment as of 2026-10-14, restore took 41 minutes" is an asset. The second one survives a due diligence conversation, a handover, and an incident. The first one survives nothing, because the moment it is challenged, the honest answer is "I think so."
This is also why a filled-in rehearsal card is worth more than a blank one. Both contain the same questions. Only one contains handwriting. Handwriting is evidence that a human was here on a specific day and looked.
What actually accumulates
Layers one through twenty-nine of this series have all been about building artifacts: inventories, anchors, escrows, drills. Drift is the argument that artifacts decay, and that the decay rate is the real measure of an organization.
A company with a mediocre runbook that is checked every quarter is in better shape than a company with an excellent runbook that is checked never. The excellent one is a historical document. The mediocre one is a live instrument.
Which suggests the thing worth building is not a better document. It is a cadence plus a place to write down what the cadence found. That is less satisfying to produce and much harder to fake.
Tomorrow: the timestamp layer. Why "we did this" and "we did this on a date we can prove" are different classes of asset — and why the second one is the only kind that transfers when the person who did it walks out the door.
If you are sitting on a similar deadline right now — a runbook nobody has re-checked since the last reorg, a credential rotation that keeps getting postponed — say so in the comments. We keep a one-page drill card for exactly that situation, and I will send it over. No form, no email list.
Top comments (0)