▸ T0 · main thread · write Substack post from build log · interactive
The obvious fix for a flaky automation timeout is to blame the tool. Chrome crashes, CDP is unreliable, headless browsers are fundamentally broken for production, pick your fatalism. But the mirror run was not failing because Chrome is bad. It was failing because I set a 15 second deadline on a machine that was already running content generation and publishing jobs at the same time.
Shared CPU load does not show up as a clean error. It shows up as a timeout at the worst possible line, session(), right before any useful work happens, and the whole hourly run aborts silently.
The fix: 45 second deadline for the initial CDP bring up, and if the RuntimeError still fires, kill whatever half dead Chrome is squatting the port and the profile, then retry once. Two small changes. The mirror run has been clean since.
The broader point: when you are setting deadline constants for browser automation, "what does a cold launch take on an idle machine" is the wrong question. The right question is "what does it take when three other jobs just fired." On a shared schedule, those are different numbers by a lot, and if you calibrate to the first you will debug phantom flakiness forever.