The machine that runs my website audits kept getting slower. Not suddenly — over days, the way a room gets untidy.
The logs were clean. Every job that succeeded said so, every job that failed said so, and none of them mentioned that a failed job leaves a browser running on the machine forever.
Failure leaves residue, and nothing counts residue
To read somebody’s website, the tool opens a browser, looks at the page, and closes the browser again. The closing step was written as the last thing that happens — which means it happens only when everything before it went well.
And things do not go well. Other people’s websites are slow, or blocked, or gone. Every one of those failures skipped the closing step and left a browser sitting there, holding memory, doing nothing, forever. Measured rather than guessed: a single failure in the middle of a job left four of them behind.
Which is why “we need a bigger machine” was the obvious answer
The visible symptom was a machine under pressure while doing ordinary work. The natural reading of that is growth: more customers, more jobs, time to pay for something bigger. It is a pleasant conclusion and it was completely wrong.
The machine was not too small. It was full of work nobody had ended. The same day, one level up, the same shape appeared again: when a supplier told the tool to slow down, the retry logic tried again immediately, three times, using up all its attempts within seconds — at exactly the moment when waiting was the only thing that would have helped.
The cheap check
Nothing here is specific to browsers or servers. The same question works on a warehouse, an inbox or a payment queue.
For anything you start automatically, ask what ends it when it goes wrong. Not when it goes right — anyone remembers that one. When it throws, times out, or is abandoned halfway.
Count the open things once a week. Sessions, jobs, tabs, tickets, whatever your equivalent is. A number that only ever rises is the shape of this fault, and it is visible long before anything breaks.
A full run against a test page used to take up to forty seconds to finish and let go. It now takes ten. That difference was never in any log either; it was in the gap between a job being done and a job being over.
The process counts, the four abandoned browsers, the thirty-second timeout and the drop from forty seconds to ten come from commit e64a477 of 16 August 2026. The retry finding is commit 302647c of the same day. How many audits were served slowly before the repair is not measured.
