Michael JohnsonIf a Durable Object call failed because of a network issue, developers often had to decide whether to send it again. Since November 5, 2026, Cloudflare’s runtime has handled some of those retries: it automatically retries certain failed fetch() and RPC calls through a stub. The key question for application code is now more specific: can a particular method safely run a second time?
The answer depends on where the connection failed. The runtime automatically retries some calls while preserving protection against duplicate execution by default. If delivery is uncertain, it uses the same request ID, and the object rejects the retry if it has already received the first attempt. An explicitly marked retryable() method behaves differently: it may run again even if the first attempt reached the object. So the marker is appropriate only for operations that are safe to repeat in terms of both state and side effects.
What the runtime retries
According to Cloudflare’s November 5 announcement, retries apply to fetch() and RPC calls to a Durable Object made by a Worker or another Durable Object. Calls through a stub get one initial attempt and up to four retries by default; no new attempts begin more than 10 seconds after the call starts.
The condition is an error with the .retryable property. For example, the request may not have reached the object because it was restarting or moving. The runtime may also retry if the connection drops and it is unclear whether the object received the request. If the object has already received it, a retry with the same ID is rejected. The runtime does not retry errors thrown by Durable Object code, errors with .overloaded, or HTTP responses such as 500: those are handler responses, not delivery errors.
Why retrying delivery is not the same as rerunning an operation
Retrying transmission of a request does not in itself mean the method runs a second time. When the outcome is uncertain, the runtime sends the request with the same ID; if the object received the original attempt, it rejects the retry. In the normal mode, this prevents a method from running again—for example, charging twice or creating a duplicate record because of a single network failure.
The boundary changes when a method is marked with retryable() from cloudflare:durable-objects. The object may then run the method again if the first attempt may already have started. Cloudflare gives two examples: setting a product’s quantity to a specified amount is idempotent; increasing the quantity by one is not. Repeating the first action sets the same value, while repeating the second adds another unit.
Check not only the final state of the store but also every effect of the method. If a retry creates another payment, sends a message, or triggers an external action, identical state inside the Durable Object does not make the retry safe. The marker is appropriate when a retry does not change the meaning of the result or duplicate side effects.
Where explicit idempotency helps
Setting a value, writing a state snapshot, or updating a field to a known value often produces the same result when repeated. For these methods, retryable() may let a call succeed after a connection drops once processing has already begun.
Operations like “add,” “create another,” “charge,” and “send” usually need a different safeguard. Before allowing a method to run again, make sure the business operation detects duplicates or is designed so a retry cannot create a second effect. The function’s name alone guarantees nothing: check every state change and external action inside the method.
retryable() has a narrow role: it permits execution to be retried when it is unclear whether the first call got through. It does not change which errors the runtime responds to or increase the number of attempts. The flag applies to the function; an overridden or wrapped version of the method does not inherit it automatically and must also be marked explicitly.
What to check in an existing project
The most likely place to review is your own retry loops around Durable Objects calls. Each application-level attempt may now include runtime retries, so the total number of requests can exceed what the application alone specifies. Cloudflare recommends reducing your own number of attempts or setting maxRetries: 0 for the stub if your code manages retries.
Limits for a particular stub are set when calling get() or getByName(). The maxRetries parameter sets from zero to ten retries after the first attempt; timeoutMs sets the interval after which no new attempts will start, from 500 to 60,000 milliseconds. These settings apply to calls through that stub. retryable() and the retry object require Wrangler 4.158.0 or later.
A useful review starts with three questions for each call: can it change state more than once; will a retry repeat external side effects; and does the application have its own retry policy? Then decide whether that stub should use the defaults or custom limits. For idempotent methods, consider an explicit marker separately; for others, keep the protection in place and check how errors are handled when the outcome of the first attempt is unknown.
The takeaway: responsibility moves to the method boundary
Automatic retries remove some network logic from application code, but whether execution may be retried remains a property of the operation. The runtime can safely retry delivery and stop if it cannot tell whether the call ran. Developers can permit a method to run again by explicitly confirming that it will not duplicate state changes or side effects.
It is therefore best to read the update as a change to the contract between the transport layer and the handler. First review your own retry loops and repeatability of side effects; then configure limits on the relevant stubs. This combines built-in resilience to brief failures with control over operations where a second run has a real cost.
