Cloudflare's 20 August 2026 Durable Objects deployments tab exposes a configured-vs-actual traffic gap

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

What changed in Cloudflare Durable Objects on 20 August 2026?

Durable Object namespaces gained a read-only Deployments tab in the Cloudflare dashboard, showing the backing Worker's live versions with requests, error rate and median wall time. The Traffic % column, for both Workers and Durable Objects, also began showing observed traffic share next to the percentage you configured for each version.

Why does the actual traffic percentage differ from the configured percentage?

For Durable Objects the configured split assigns versions to individual objects rather than to individual requests. Each object stays pinned to its version until you create a new deployment, and objects carry uneven traffic, so observed share can differ from configured share for as long as multiple versions remain active.

Does version affinity fix the Durable Objects traffic split?

No. Version affinity pins a user to one version through the Cloudflare-Workers-Version-Key header, and it operates on requests. Durable Object version assignment happens at the object level, so affinity does not change the split. Affinity also needs Transform Rules, which are unavailable for Workers served on workers.dev domains.

Can I roll back a Durable Object gradual deployment?

Not past a class lifecycle change. Cloudflare states that versions changing Durable Object class lifecycle cannot be uploaded, covering the exports field and the legacy migrations array, because lifecycle changes are atomic. Once deployed, rollbacks cannot reach any version prior to the one containing that change.

How reliable is the actual traffic share number?

It comes from the GraphQL Analytics API, which uses Adaptive Bit Rate sampling at 100%, 10% or 1% resolution depending on query complexity, time range and system load. Durable Objects analytics can also lag Workers analytics by several minutes, so treat small gaps as noise and sustained large gaps as real distribution.

What does a Durable Objects gradual deployment cost?

Pricing does not change during a rollout. The Workers Paid plan includes 1 million requests and 400,000 GB-s monthly, then charges $0.15 per million requests and $12.50 per million GB-s, with duration billed against a fixed 128 MB allocation per object regardless of actual memory used and rounded up to the next billable unit.

How do I get an unsampled count of invocations per version?

Add the version metadata binding to the Worker and log the version identifier from inside the Durable Object, then count log lines per version. Workers Logpush also exposes a ScriptVersion object containing id, message and tag fields, which can currently be added only through the Logpush API rather than the dashboard.

How many versions can a gradual deployment use?

A gradual deployment can only be created from the last 100 uploaded versions of a Worker, per Cloudflare's gradual deployments documentation. Separately, only one version of any given Durable Object runs at a time, because global uniqueness guarantees a single instance of a class with a given ID worldwide.

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.