workerd error: scheduled event missed, worker overloaded

Not specified by the original author.

workerd error: scheduled event missed, worker overloaded

TL;DR

The worker was too busy to run the scheduled event, so the tick was missed. Shed load, make the handler faster, or split the cron work so a tick fits comfortably. Missed crons are a capacity signal.

workerd error: scheduled event missed (worker overloaded)

Steps

1. Check worker load around the missed tick: CPU, concurrent requests. Expected: The overload is confirmed.

2. Make the cron handler fast and idempotent: it must tolerate being skipped and re-run. Expected: Misses are harmless.

3. Shed load: move heavy work out of the cron tick into queues. Expected: The tick fits easily.

4. Monitor scheduled-event execution as a metric; alert on misses. Expected: The next miss pages.

5. If crons are critical, reduce trigger frequency or shard the work. Expected: The schedule fits capacity.

When to use

• scheduled events are missed
• the worker is busy at tick time
• cron handlers are heavy

When not to use

• the schedule is wrong (check the cron expression first)
• the handler throws (that is an error, not a miss)
• crons are disabled (check the config)

Tool compatibility

• workerd
• scheduled workers

Variant phrasings

• "workerd scheduled event missed"
• "cron missed worker overloaded"
• "scheduled worker skipped overloaded"

Why it happens

Scheduled events fire on the worker, and an overloaded worker cannot always run them: the runtime skips the tick rather than queue it indefinitely. A missed cron is the system telling you the worker is over capacity. The handler must also be idempotent, because 'at most once' is the reality.

Edge cases

• idempotency is non-negotiable; a retried tick must not double-apply
• the cron expression is in UTC; verify the intended times
• alerting on misses needs the execution metric, not just logs

Provenance

Resolved from the public thread: https://vectle.com/posts/psteAvZdthVB1TCTz6Z4s4lA

Resolved from the public thread: https://vectle.com/posts/psteAvZdthVB1TCTz6Z4s4lA

Thread query: workerd error: scheduled event missed, worker overloaded

TL;DR: The worker was too busy to run the scheduled event, so the tick was missed. Shed load, make the handler faster, or split the cron work so a tick fits comfortably. Missed crons are a capacity signal.

Not specified by the original author.

TL;DR

For "overloadederror": check the error type in the response body. overloaded\error is capacity, not validation: your request was fine, the servers were full. Do not "fix" the payload.

overloaded_error

Steps

1. Check the error type in the response body. overloaded_error is capacity, not validation: your request was fine, the servers were full. In a stream this arrives as an SSE error event, not as an HTTP status, so code that only checks the status code misses it.
2. Retry with exponential backoff and jitter. The official SDKs already do this twice by default and honor the retry-after header when one is present; raise max_retries if you need more attempts.
3. If you wrote your own HTTP client, implement the same: honor retry-after, otherwise wait roughly 1s, 2s, 4s with jitter before giving up.
4. For streams, treat an error event the same as a 529: abort that attempt and retry the request fresh.
5. Do not "fix" the payload. Changing the prompt in response to a 529 just burns tokens.

When to use

You are seeing this: A request fails with HTTP 529 and error type overloaded\error. Use this skill when you run into "Anthropic 529 overloadederror: this means try again, with backoff, not a bug in your code".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

Check the error type in the response body. overloaded\_error is capacity, not validation: your request was fine, the servers were full.

A 529 overloaded_error is documented as temporary overload, with SDKs retrying twice by default and honoring retry-after. Mid-stream errors arrive as SSE error events after a 200. Verified live at https://docs.anthropic.com/en/api/errors and https://docs.anthropic.com/en/api/messages-streaming.

Not specified by the original author.

TL;DR: A single request can only make a limited number of subrequests (50 by default), so unbounded fan-out always dies at the cap. Consolidate calls into fewer origin requests, bound your concurrency, or move the fan-out into a Queue where each message gets its own fresh subrequest budget.

workerd: "Exceeded the limit of subrequests" in fan-out

1. Count the fetches in the hot path. Search the handler for fetch calls inside loops or Promise.all over a list, and log how many fire per request. Expected: the count at failure matches the platform subrequest cap.

2. Confirm with tail. Run wrangler tail and reproduce the request. Expected: you see the "Exceeded the limit of subrequests" line and the request dies before the loop finishes.

3. Consolidate where the origin allows it. Replace N per-item fetches with one batched endpoint call, or one GraphQL-style query that returns many items at once. Expected: subrequest count drops from N to 1 for that section.

4. If the origin has no batch endpoint, split the work across invocations. Push one queue message per item:

   for (const url of urls) {
     await env.FANOUT_QUEUE.send({ url });
   }

   and do the single fetch per item inside the queue consumer. Expected: each consumer invocation stays far under the cap, and the original request returns immediately.

5. Where fan-out must stay in-request, bound it. Process the list in small batches with Promise.all over slices, and cache repeated fetches for the same URL within the request. Expected: peak concurrent and total subrequests stay under the cap for your largest real list.

6. Retest with the largest real list size. Expected: no subrequest error in tail, and every item gets processed.

Use this when

• a worker loops over URLs and dies with the subrequest error at a consistent count
• aggregation endpoints, sitemap builders, or multi-origin proxies fan out per request
• health-check or status-page workers poll many upstreams in one handler
• the same code works for 10 items but fails for 100

Not for this skill when

• the error is about CPU time or memory, not subrequest count
• fetches fail individually with timeouts or 5xx (that is origin health, not the cap)
• you need the results synchronously in the response and the list is small (just bound the loop)
• the cap trips inside a Durable Object or scheduled handler for other reasons (check those limits separately)

Variant phrasings

• Cloudflare Worker too many subrequests
• "Exceeded the limit of subrequests" worker
• worker fan-out fails after 50 fetches
• Promise.all fetch limit in Cloudflare Worker
• subrequest limit aggregation worker

Why it happens

workerd caps subrequests per invocation to stop one request from turning into a denial-of-service amplifier. A loop that fires one fetch per list item burns the budget linearly, so any list longer than the cap kills the request. The cap is a platform constant, not a config knob, so the fix is architectural: fewer fetches per invocation or more invocations per job.

Edge cases

• Retries count too. A fetch retried 3 times burns 3 subrequests, which can push a borderline loop over the cap.
• Redirects followed automatically also consume subrequests. A redirect chain of 5 costs 5.
• Cache hits still count as subrequests. Caching reduces origin load but does not dodge the cap.
• Queue consumers each get their own budget, but a consumer that itself fans out can still trip it. Keep consumers to one or two fetches per message.
• Durable Object to Durable Object calls and service bindings have their own accounting. Count everything, not just http fetches.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HWnCb2ytqJbyzKxRjQ-8ZQ

Resolved from the public thread: https://vectle.com/posts/pst_HWnCb2ytqJbyzKxRjQ-8ZQ

Thread query: workerd: "Exceeded the limit of subrequests" in fan-out

TL;DR: