On this page · 10 sections
Summary. On 20 August 2026 Cloudflare gave Durable Object namespaces their own Deployments tab and added a second number to the Traffic % column across both Workers and Durable Objects: the actual, observed traffic share for each version, printed next to the percentage you configured. Cloudflare's own changelog explains why the two numbers drift, and the explanation is the story. For Durable Objects the configured split "assigns Worker versions to individual Durable Objects, not to individual requests", so a 50/50 configuration on a namespace where one object carries most of the load will never read 50/50 in the dashboard. The three documentation pages a team would consult to interpret that number were last updated 3 July 2026 and 15 July 2026, five to seven weeks before the feature that changed what the number means. Durable Objects bill at $0.15 per million requests and $12.50 per million GB-s above the Workers Paid allocation of 1 million requests and 400,000 GB-s per month, and duration is charged against a fixed 128 MB allocation per object regardless of actual memory use, so a stalled rollout that leaves two versions live is a billing event as well as a correctness one.
What Cloudflare shipped on 20 August 2026
The changelog entry has a datePublished of 2026-08-20 and covers two changes that arrived together.
The first is navigational. A Durable Object namespace is backed by a Worker script, so its deployments have always been that Worker's deployments; until now, checking a gradual deployment in progress meant leaving the namespace and opening the backing Worker. The new tab surfaces live versions, requests per second, error rate and median wall time on the namespace itself. It is read-only. Cloudflare is explicit that "promoting, rolling back, or splitting traffic on a deployment is still managed from the backing Worker's Deployments tab", so the tab is a reading surface, not a control surface.
The second change is the one that matters, and it is not limited to Durable Objects. The Traffic % column, "for both Workers and Durable Objects", now prints observed share beside configured share. Cloudflare's stated reason for adding it: when you move a deployment from 50/50 to 100% on a new version, "the configured number updated immediately, but requests take time to catch up, and there was no way to tell how far along that shift was without checking metrics elsewhere."
That framing describes a lag. For Durable Objects it is not a lag.
The conflict: request-level routing versus object-level assignment
Three Cloudflare pages describe what a configured percentage does, and they do not describe the same mechanism.
| Page | Last updated | What the percentage routes |
|---|---|---|
| Gradual deployments | 3 July 2026 | "each request is independently routed to a version based on the configured percentages" |
| Gradual deployments with Durable Objects | 15 July 2026 | "each Durable Object is assigned a Worker version based on the percentages you configured" |
| Changelog, 20 August 2026 | 20 August 2026 | "assigns Worker versions to individual Durable Objects, not to individual requests" |
The parent page is the one most teams read first, and it is the one that is wrong for Durable Objects. Its own Durable Objects section points down to the sub-page, but the version-skew section immediately above it states the request-level rule without qualification. A release engineer who reads the parent page and configures 20% on a new version is expecting roughly one request in five to hit it. What they get is roughly one object in five, weighted by however much traffic those objects happen to carry.
Cloudflare now says so plainly in the changelog: because each object "is pinned to the version it started on until you create a new deployment" and "some objects naturally receive more traffic than others, the observed split can differ from the configured one for as long as multiple versions are active." Not until analytics catch up. For as long as the deployment is live.
The sub-page, dated 15 July 2026, is five weeks older than the changelog and never mentions traffic-weighted skew at all. It offers a clean worked example in which versions A and B are assigned across three objects named foo, bar and baz, and three guarantees: requests to a given object always use the same version for a given deployment; increasing a version's percentage in the same order never reverts an object that already moved; and each object is reset only once. Those guarantees are about assignment stability. None of them is a guarantee about traffic share, and a reader can finish that page believing the configured number is a traffic number.
What actually breaks
Version affinity does not fix this. Cloudflare's documented answer to version skew is version affinity, last updated 3 July 2026, which pins a user to one version by setting the Cloudflare-Workers-Version-Key header. The page's headline failure case is content-hashed static assets: without affinity a user "can receive HTML from version A, but when their browser requests index-a1b2c3d4.js, that request may be routed to version B - which does not have that file - resulting in a 404 error and a broken page." That mechanism operates on requests. Durable Object assignment does not, so affinity gives you nothing on the namespace. It also carries its own limit: the recommended way to set the header is a Transform Rule, and Transform Rules "are not available for Workers served on *.workers.dev domains."
The canary signal is diluted. If 20% of objects hold 3% of traffic, a 20% canary is a 3% canary and the error rate on the new version is being measured on almost nothing. The new tab is what makes this visible, which is the argument for adopting it. Read the actual column, not the configured one, before you judge a version healthy.
Rollback has a hard floor. The Durable Objects sub-page states that versions changing Durable Object class lifecycle "cannot be uploaded" gradually, covering both the declarative exports field and the legacy migrations array, "because Durable Object lifecycle changes are atomic operations. Once a lifecycle change is deployed, rollbacks cannot take place to any version prior to the one that included the change." Cloudflare's reasoning is concrete: a class deletion applied to half the instances would fail every Worker requesting a deleted object. The practical rule from the same page is to deploy lifecycle changes with wrangler deploy, alone, separately from other code changes.
The number you are reading is sampled. Actual share comes from the GraphQL Analytics API, and Cloudflare's sampling FAQ, last updated 23 April 2026, describes Adaptive Bit Rate sampling storing data at 100%, 10% and 1% resolutions and selecting between them by query complexity, time range and system load, against a pipeline handling "over 700 million events per second". Its own example: the same 30-day query returning 3,500 objects once and 3,600 another time. On top of that, the changelog warns that "Durable Objects analytics can lag Workers analytics by several minutes". A one-point gap between configured and actual is noise. A twenty-point gap that holds for an hour is the distribution.
Version skew lasts longer than you think. The known issues page, last updated 3 July 2026, notes that code changes roll out in an eventually consistent way and that a request can hit the latest Worker version which then calls an object still running the previous version, "typically seconds to minutes" - and that under a gradual deployment "this period of time is determined by how long your live deployment is configured to use more than one version." Forwards and backwards compatibility between a Durable Object and its Worker is not optional here.
Who this affects, and how to tell if it is you
You are exposed if a Worker bundle exports a Durable Object class and you use wrangler versions deploy with any split other than 100%. You are exposed further if object traffic is uneven, which is the normal case: per-tenant, per-room, per-document and per-user namespaces all concentrate load on a minority of objects.
| Signal | Where to look | What it means |
|---|---|---|
| Actual % far from configured %, stable over an hour | Namespace Deployments tab, Traffic % column | Traffic-weighted object skew, not ingestion lag |
| Actual % converging over several minutes | Same column, after a change | Analytics lag; wait before acting |
| Error rate near zero on a new version at low actual % | Per-version metrics on the tab | Canary too thin to be evidence |
| Two versions live for days | Deployments tab | Prolonged skew window, and duration billed per version |
| Upload rejected for a version | wrangler versions upload |
Class lifecycle change; deploy it alone with wrangler deploy |
A practical check that needs no dashboard: add the version metadata binding and log the version ID from inside the Durable Object, then count log lines per version. That gives an unsampled count of real invocations per version. Workers Logpush also carries a ScriptVersion object with id, message and tag, addable only through the Logpush API today, per the gradual deployments page.
The cost side
Durable Objects pricing, last updated 10 August 2026, puts the Workers Paid allocation at 1 million requests and 400,000 GB-s of compute duration per month, then $0.15 per million requests and $12.50 per million GB-s above that. Billable usage is rounded up to the next billable unit before the rate applies, so 500,000 GB-s of billable duration bills as 1,000,000 GB-s. Duration is charged for the 128 MB an object is allocated "regardless of actual usage", and objects that share an isolate are each still billed for a full 128 MB. The Workers Free plan allows 100,000 requests and 13,000 GB-s per day and only SQLite-backed classes.
None of that changes during a gradual deployment, but the shape of the exposure does. A deployment parked at 50/50 keeps two versions of the backing script live, and every object that is awake and ineligible for hibernation accrues duration on whichever version it was pinned to. The real cost of a stalled rollout is usually the duration meter, not the requests. Teams doing this at volume tend to find the same thing in their Cloudflare Workers versus Vercel Functions cost comparisons: the per-request line is small and the wall-clock line is not.
There is also a ceiling worth knowing: gradual deployments can only be created from the last 100 uploaded versions of a Worker.
India-specific considerations
Indian teams running multi-tenant SaaS on Durable Objects usually shard by tenant, which is precisely the pattern that produces uneven object traffic. A 25% canary across 400 tenant objects can put a single large enterprise tenant on the new version and nothing else that matters, or miss every large tenant entirely. Neither outcome is visible from the configured percentage alone.
For workloads holding personal data, note that a Durable Object's version assignment is independent of where the object lives, and the Digital Personal Data Protection Act 2023 obligations attach to the data, not the deployment. A gradual deployment does not create a new residency question, but it does create a window in which two code paths write the same stored records, and schema-compatibility discipline across that window is a data-integrity control as much as a release one.
What is still unknown
Cloudflare has not published a threshold at which a configured-versus-actual gap should be treated as a problem rather than as normal distribution. It has not stated the confidence interval on the actual figure, though the sampling FAQ recommends requesting confidence intervals in GraphQL queries generally. It has not said whether the parent gradual deployments page will be corrected to qualify the request-level claim for Durable Objects. As of 23 August 2026 that page still carries a 3 July 2026 dateModified and the unqualified sentence.
FAQ
How eCorpIT can help
We run release engineering for teams on Cloudflare Workers and Durable Objects, including canary sizing that accounts for object-level assignment rather than request-level percentages, version-metadata logging so rollout evidence is unsampled, and schema-compatibility review across the skew window. Our senior engineering teams work to CMMI Level 5 and ISO 27001:2022 practice. If a rollout is parked at a split you cannot interpret, book a Cloudflare release engineering review and we will read the deployment with you. Teams starting from scratch may want the Cloudflare Agents SDK Durable Objects production guide first, or the wider cloud cost reduction playbook for Indian teams.
References
Last updated 23 August 2026.
