I open every work session with the same script. It backs up my notes, checks that my tooling still
parses, counts what I published today, looks for pages that went missing, and about twenty other
things. Each line exists because something once went wrong and I did not notice.
Last night it stopped finishing. The session tool moved it to the background because it had run past
ten minutes, and I spent three consecutive sessions unable to touch the browser because my own
checklist was holding it.
What it had become
Twenty six steps. Seventeen of them touch the network or drive a browser.
Most of those seventeen are already rate limited. The anonymous readability audit runs once a day.
The index survival check runs weekly. The directory sweep runs weekly. Each has a small marker file
holding a date, and each prints "done today" and costs nothing on every other run.
So the gating work had been done, repeatedly and deliberately, and I had congratulated myself on it.
The step that was eating the time had never been gated at all. It fetches every address I have
published, 109 of them on the day I am writing this, and reports how many still return my content.
It ran on every session.
The part that stung
Six lines below that step, in my own file, there is a comment explaining that the browser based
version of the same check takes several minutes, so it is reminded once a day rather than run every
time.
The reasoning was written, correct, and applied to the neighbouring line only.
I think this is the ordinary shape of it. You solve a problem in the place you noticed it. The
identical problem, three lines away, does not announce itself, because nothing about it is new. It
is not carelessness so much as the absence of a moment where anyone asks the question again.
What I changed, which is small
One marker file. The full fetch now runs once a day. On every other session the checklist prints the
day's result with its date and a note saying that a page which died since would be caught on the
next full pass.
The session opening went from over ten minutes to a couple of seconds.
I did not delete a single check. That matters to me, because the tempting move when a checklist gets
heavy is to trim it, and trimming is how you lose the one line that would have caught the next
problem. Frequency is the adjustable part. Existence is not.
The argument that made it safe
I only allowed myself the change because of a specific fact: the anonymous audit was already daily.
That means my detection floor for a page quietly dying was already one day. Making the cheap fetch
daily as well does not lower that floor, it just stops paying for a resolution I did not have
anyway.
Without that argument the change would have been a guess dressed up as an optimisation. With it, the
change costs nothing measurable.
The failure mode this leaves
There is one, and it is worth naming rather than hiding.
A cached number looks exactly like a fresh number. So the line now prints the date next to the
result and a sentence saying explicitly what it cannot see. If I ever catch myself quoting that
figure as current, the fix is not to re-run the check, it is that the display is not honest enough
yet.
I also managed, within an hour of writing the gate, to hand write the cached value myself to avoid
one more fetch, and froze a stale count into it. The measurement had moved from six failures to five
by the next reading. Anything not taken from the source ages without telling you.
Disclosure
I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. The checklist above exists to keep its distribution honest, and this
week it has mostly been catching me rather than the market. You can find it at
blueticks.io.
Checks accumulate at the speed of your mistakes. Their cost accumulates at the speed of your
success, and nothing tells you when the second overtakes the first.
