Why Durable Objects Still Run Old Code for 5 Minutes After Deploy

Deploy a Worker that hosts Durable Objects, watch traffic keep flowing, and the instance may still execute the previous code for up to about five minutes. The usual cause is the default deferred update policy. From 2026-10-30, Cloudflare's Durable Objects documentation and Changelog set the default code update strategy to deferred, with a default max_delay of 300 seconds. Active objects can keep the current version until they hibernate—or until that delay expires and the runtime resets them onto the new code.

For AI agents, long-lived sessions, or Hibernation WebSocket workers on Durable Objects, the practical question is when a deploy actually flips the code. The Cloudflare Changelog dated October 30, 2026, and the Durable Objects code-updates docs (last updated the same day) set the rules below. We haven't tested every Wrangler, gradual traffic, and REST Create deployment path yet; prior live reports can go through the site-owner contact at the bottom.

Related on-site context: Cloudflare Fixed Cross-Request KV Cache Exposure in Workers AI GLM-5.3, AWS Opens Infinity, a Research Runtime for Extreme Agent Concurrency, Cursor Agent SDK Is Out: Folders, Eval, and Deploy, and Same Model, Different Coding Harness: Pass Rate Barely Moves, the Bill Does.

What changed on 2026-10-30

Before this default, many teams assumed “deploy finished” meant every Durable Object instance had already switched. The Changelog and Durable Objects documentation now state the opposite baseline:

• Default mode: deferred
• Default delay: max_delay = 300 seconds (5 minutes) when the field is omitted
• Allowed range: 0–86400 seconds (24 hours), with millisecond precision where the API accepts it

An active Durable Object may continue running its current code until it hibernates or hits max_delay. When the delay elapses while the object is still active, the runtime resets the object and loads the new code. After hibernation, the next request that wakes the object uses the new version.

That is why a deploy can look green in CI while a sticky agent session, alarm handler, or WebSocket still behaves like yesterday's build for several minutes.

immediate versus deferred

Two modes matter in practice:

A compact form also exists: { "mode": "deferred", "max_delay": 0 } applies the update immediately—equivalent in effect to forcing a zero wait under deferred semantics. An explicit immediate keeps the intent “reset now” readable six months later.

Hibernation WebSockets. The Changelog notes that WebSockets using the Hibernation API can keep the connection when the object hibernates and later adopts new code. That is useful for agent UIs and long chat sockets—and “connection still up” is not the same as “code already swapped.” We haven't tested every Hibernation WebSocket path against the 2026-10-30 default; the Changelog wording is the source of record.

Wrangler: durable_objects.code_update_strategy

In wrangler.toml / Wrangler config, set the strategy next to Durable Object bindings (same level), including Workers that only expose classes through ctx.exports with no explicit binding list:

[durable_objects]
# illustrative shape — field names per current Wrangler schema
code_update_strategy = { mode = "deferred", max_delay = 300 }

Exact TOML / JSON encoding can vary by Wrangler generation; the Durable Objects documentation names the field durable_objects.code_update_strategy with mode and optional max_delay. When the block is omitted, that deploy falls back to the platform default { deferred, 300 }—and the choice does not inherit automatically into the next deploy. Each deploy that omits the field returns to the default again.

CLI flags beat config, and deferred needs a duration

Wrangler CLI flags apply to wrangler deploy, versions deploy, and rollback:

• --durable-objects-code-update-mode immediate
• --durable-objects-code-update-mode deferred <duration> — for example deferred 30s

Per the Durable Objects documentation (not only the Changelog examples): when the mode is deferred on the CLI, a duration is required. Priority is:

1. CLI flag
2. Wrangler config (durable_objects.code_update_strategy)
3. Platform default { deferred, 300 }

Changelog samples often highlight immediate. The Docs rule still binds: CLI deferred must carry a duration.

Consecutive deploys and independent timers

Ship version A, then B, then C while the same object stays active, and each deploy starts its own max_delay timer for that object. When the earliest timer fires, the object adopts the newest version already deployed at that moment—not necessarily the version that started the timer. An immediate deploy in the middle can force an update right away and skip intermediate versions.

Implication for AI agent fleets: rapid successive deploys do not queue “A then B then C” as three guaranteed soft landings. Timers race; the survivor is the latest code present when the first timer expires (unless an immediate deploy already forced a cut).

Gradual deployments

When a gradual rollout raises the traffic percentage for a Worker version, the deferred / immediate mechanism applies to objects newly graduated onto that version. Objects already on that version are not re-delayed by the percentage bump. Code that may run side by side across versions still needs to stay forward- and backward-compatible for Durable Object state and protocol.

REST Create deployment: write-only field

The Create deployment request body may include code_update_strategy. The field belongs to the deployment, not to the Worker version resource. It is write-only: Create, get, and list responses do not echo the strategy. Operators who round-trip deployment JSON looking for a saved mode will not find it in the response payload—set it again on the next Create if a non-default policy is required.

Scope: which classes share a strategy

All Durable Object classes exported by the same Worker share one strategy for that deploy—including classes reached only via ctx.exports. When a class is referenced through script_name from another Worker, the referenced Worker's own strategy controls that class. Cross-script binding does not silently adopt the caller's deploy policy.

Best effort—and what the strategy does not cover

deferred is explicitly best effort in the Durable Objects documentation:

• It does not guarantee every in-flight operation finishes cleanly before the switch.
• It does not guarantee the object runs for the full max_delay (platform events can still reset earlier).
• The strategy does not delay restarts that are unrelated to shipping a new Worker version—for example a Workers runtime update.

So deferred is best effort only: it does not promise zero downtime, finished in-flight work, or lower cost. We haven't measured interruption rates or bill impact under the 2026-10-30 default.

Operator checklist for agent and WebSocket workers

1. Default since. From 2026-10-30, deferred + 300s is the expectation unless config or CLI says otherwise.
2. Intent. Hotfix that must cut over now → immediate (or deferred with max_delay: 0 only if that form is deliberate). Long sessions that can wait for hibernation → deferred with an explicit max_delay.
3. CLI deferred needs a duration. deferred 30s (or another duration)—bare deferred without a duration fails the Docs rule.
4. Strategy each deploy. Omission returns to the platform default; nothing is inherited across deploys.
5. Consecutive deploys. Independent timers; earliest expiry takes the newest deployed version.
6. Gradual ≠ re-delay everyone. Only newly graduated objects enter the delay path for that version.
7. REST responses. code_update_strategy is write-only on Create deployment; responses do not echo it.
8. Hibernation WebSockets. Connections may survive hibernation and code adoption; the application protocol still needs a separate check. We haven't tested every socket edge case here.
9. Compatibility. Durable Object storage and message formats stay compatible across versions that can overlap during deferred windows and gradual moves.
10. Related Workers AI note. Cache and isolation bugs elsewhere on the Workers AI surface are a different topic—see the GLM-5.3 KV cache write-up linked above.

Bottom line

Durable Objects can keep serving old code for up to five minutes after a successful deploy because, from 2026-10-30, deferred with a 300-second default max_delay is the platform baseline. immediate fits when a reset is the correct product behavior; deferred fits when waiting for hibernation is acceptable—and deferred remains best effort—it does not guarantee completion or uptime. The live CLI and config schema in the Durable Objects documentation are the check before production deploys change.