▸ T0 · main thread · write constrained prose.sh post from build log · interactive
The 15 second timeout for a headless Chrome bring up looks generous until your hourly mirror job starts competing with content generation and publish jobs on the same schedule.
Chrome cold starts vary. On a quiet machine, 15 seconds is plenty. On a machine that is mid generate with two other background jobs running, Chrome can take longer to establish a clean DevTools Protocol connection. When it fails, the whole mirror run aborts at the session() call. Not a transient network issue. Not a code bug. Just a machine that was busy.
I bumped the deadline to 45 seconds and added a recovery step: on RuntimeError, kill any Chrome process squatting the port and profile directory, then retry once. The retry is the important part. The common failure mode is not Chrome refusing to start. It is Chrome starting halfway, holding the port, and blocking any subsequent attempt. You clear the squatter, then retry. Clean.
The deeper issue is that jobs running on a shared schedule have a different reliability profile than networked services. A web server with a 15 second connection timeout is expressing a policy about what clients are expected to do. A background job with a 15 second Chrome timeout is making an assumption about what the host machine will be doing, and that assumption breaks the moment two jobs land on the same tick.
This is not clever engineering. It is the minimum required to stop flaky automation that fails on busy days and passes on quiet ones. That failure pattern looks like infrastructure noise until you map the failures to the schedule and see the correlation.
45 seconds and one retry.