workerd: setTimeout clamped to 30 seconds, timeout-based retry broken

Fix setTimeout clamped to 30 seconds, timeout-based retry broken

TL;DR

Do not use setTimeout for waits longer than 30 seconds in Workers - the runtime clamps the timer and your retry fires early. Keep in-request delays under 30 seconds, and move longer waits to a Queue with delaySeconds, a Durable Object alarm, or a cron trigger.

Verbatim error

workerd: setTimeout clamped to 30 seconds, timeout-based retry broken

Steps

1. Confirm the clamp: log the requested delay and the actual elapsed time around the timer. Expected: delays over 30 seconds fire at roughly 30 seconds.
2. For backoff that fits inside a request, cap each delay at 25 seconds and keep the total retry budget small. Expected: retries fire on the schedule you set.
3. For longer waits, switch to a Queue: send the retry as a message with delaySeconds set. Expected: the message redelivers after the requested delay.
4. Alternative for one-shot future wakeups: use a Durable Object alarm(). Expected: the alarm fires at the target time.
5. Alternative for periodic retries: use a cron trigger that picks up pending work. Expected: the trigger runs on schedule.
6. Verify by tailing logs around the expected fire time. Expected: the retry runs at the intended delay, not at 30 seconds.

Use this when

• setTimeout(60000) fires at 30 seconds in a Worker
• Exponential backoff stalls or collapses to a fixed 30-second rhythm
• Logs mention timer clamping in workerd

Not for this skill when

• All your timeouts are under 30 seconds (they work fine)
• You need a request-scoped deadline inside the CPU limit (different pattern)
• The problem is setInterval drift rather than the clamp (same fix family, but check the interval logic)

Variant phrasings

• workerd timer max 30 seconds
• setTimeout not working long delay cloudflare workers
• retry backoff broken workers
• timeout clamped workers runtime

Why it happens

Workers are event-driven isolates without long-lived processes, so the runtime caps timers at 30 seconds to bound isolate lifetime. The design intent is short-lived execution: anything that needs to happen later should be scheduled through queues, crons, or alarms rather than held in a timer.

Edge cases

• setInterval has the same 30-second clamp.
• Timers keep running during streaming responses but are still capped at 30 seconds.
• There is no unref() in workerd; do not port Node timer patterns blindly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5oU6qXmn4NzeEJ5-xhTwvQ