Self-Healing CI: Recovering a Slow Cold Start That Times Out a Step
A step that times out waiting for something to warm up was slow to start, not stuck -- once it is warm, the same step completes well within budget.
The problem
A step times out waiting for a service, function, or container to become responsive on its first invocation -- a cold start. The thing being waited on is healthy; it just needed longer to initialize on the first hit. A human re-runs the job (now warm) or extends the wait and it passes unchanged.
Error: timed out waiting for service to become healthy (cold start)
# the next invocation responds immediately once warmWhy it happens
A cold start pays one-time costs the first time something runs -- spinning up a container, loading code, establishing connections, JIT warmup -- so the first invocation can be far slower than every one after it.
A fixed wait sized for warm latency can be crossed by that one-time warmup, producing a timeout even though the service is healthy and responds instantly once warm.
The manual fix
Manual handling for cold-start timeouts:
- Re-run the job once the dependency is warm, or pre-warm it before the dependent step.
- Increase the readiness/wait timeout enough to absorb the first-invocation warmup.
- Add a readiness poll that waits for a healthy response instead of a fixed sleep.
How this gets automated
A cold-start timeout is distinguishable from a genuine hang by whether a retry (now warm) completes promptly. A self-healing CI pipeline detects the warmup-driven timeout, waits for readiness and retries, and only escalates if the dependency stays unresponsive, which is the real signal of a broken service rather than a slow first start.