On November 5, 2026, Cloudflare changed the default behavior of calls to Durable Objects (the stateful coordination component of Workers). The runtime now retries fetch() and RPC calls on its own when they fail with an error marked as retryable before reaching the object. Nothing needs to be turned on: it applies to calls made by a Worker or by another Durable Object.
What the runtime now does
According to the automatic retries documentation, the default is up to five attempts in total (the original plus four retries), with exponential backoff and jitter between them. No retry starts more than 10 seconds after the original call began.
The runtime retries in two cases: when the request never reached the object (for example, because it was restarting or moving to another machine), and when the connection dropped and the runtime cannot tell whether the object received the call. In the second case, the retry carries the same identity as the first attempt, and the object rejects it if it already received the original. Per the documentation, a method never runs twice because of a retry.
Left out are errors thrown by your own code, errors with .overloaded set to true, HTTP error responses such as a 500, ReadableStream bodies, RPC arguments containing streams, stubs or functions, calls using promise pipelining, and stubs received from another Worker rather than created from the namespace. Retries do not count toward the subrequest limit.
Who needs to look now
Teams running products on Workers that use Durable Objects for carts, sessions, queues, chat rooms or counters. The case that needs attention is code that already wraps object calls in its own retry loop. Cloudflare warns in the changelog itself that each of your attempts now includes the runtime's retries. A loop with three attempts can become up to fifteen sends to the object and, in the worst case, hold the user's request for 30 seconds or more before returning the error, since each of your attempts can wait up to 10 seconds for the runtime's retries. That arithmetic is mine, based on the documented default limits.
Anyone who never wrote retries for Durable Objects gets protection against short failures without changing anything. For that group, the visible effect will likely be fewer sporadic errors and some extra latency on calls that used to fail fast.
What to do
There is no deadline, because the change is already live. The work is a code review:
- Look for retry loops around Durable Object stubs. Where your code already controls attempts, reduce their number or create the stub with
retry: { maxRetries: 0 }inget()orgetByName(). The field accepts 0 to 10 retries, andtimeoutMsaccepts 500 to 60,000 milliseconds. - Review timeouts on routes that call objects. A 10-second ceiling for starting retries may not fit a route with a short response budget; in that case, lower
timeoutMson the stub. - Mark with
retryable(), fromcloudflare:durable-objects, only idempotent methods, those where running twice leaves the same result (setting a quantity, not adding an item). Without the mark, when the connection drops after the method has started, the object refuses the retry and the error reaches your code, as before.
To use retryable() and the retry option, the project needs Wrangler 4.158.0 or later. The retries themselves do not depend on that update.
What is still unclear
The documentation does not say how retries show up in logs and usage metrics, so it is not yet possible to tell whether a latency increase on the dashboard comes from them. There are also no figures on how often these failures happen in production, which leaves open how many sporadic errors the change should remove. Finally, the note covers calls through stubs created from the namespace; anyone passing stubs between Workers over RPC still gets no automatic retry and needs to keep their current handling.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
