What kills a scheduled job faster than a bug in your code? A timeout you set when the machine was idle and never revisited.
My Medium mirror runs hourly. It spins up a headless Chrome session to scrape and repost. When I first set the CDP launch timeout, 15 seconds felt generous. Then the machine started running content generation and publish jobs on overlapping schedules, and a cold Chrome launch started taking longer than that. The whole mirror run aborted at the session line, silently, every time the machine was busy.
The fix was mechanical but the lesson was not. I bumped the deadline to 45 seconds and added one recovery pass: if the launch throws a RuntimeError, kill whatever half dead Chrome process is squatting the port or the profile, then retry once. Two lines of logic, no retries forever nonsense, no exponential backoff theater.
The tradeoff I accepted: a failure now costs up to 90 seconds instead of 15 before the run bails. That is the right call. You want your retry budget to be large enough that a legitimately slow cold start succeeds, not so large that a genuinely broken environment hangs your scheduler for minutes. 45s covers the realistic worst case on a loaded machine. One retry covers transient port contention. Two retries would just be wishful thinking with extra latency.
Timeouts you set in development are wrong for production. Not wrong in concept, wrong in value. The machine was quiet when you picked the number.