PuppyIP Resource Center
Cloud Operations 4 min read Published 2026-11-12

Cloudflare Durable Objects routing: which connections improve, and what does p99 mean?

On November 11, Cloudflare announced improved Durable Objects request routing. Destination lookup no longer acquires an intermediate connection first, potentially reducing p99 connection latency for relocation-related requests without code or configuration changes. Separate connection establishment from the business call, then use existing monitoring to assess your workload. The announcement provides no universal speedup.

Cloudflare Durable Objects Request routing Connection latency

Service eligibility and regional restrictions

PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.

Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.

Key Takeaways

  • When the first data center does not know an object’s location, the new path returns the destination directly so the caller can connect, avoiding an intermediate connection and duplicate acquisition.
  • The potential benefit concerns p99 connection latency for relocation-related requests. Results depend on workload and traffic.
  • namespace.get() often returns a stub before a connection exists. Timing that method alone does not measure connection establishment.
  • No code or configuration changes are required. The announcement does not provide a universal gain or a complete plan, pricing or regional list.

Where does the connection path become shorter?

A Durable Object is a Cloudflare-managed stateful object accessed through a local calling handle, or stub. The November 11, 2026 update concerns the connection path during destination lookup. When the object’s destination is not cached, the first data center contacted may hold a forwarding record pointing to another data center.

Previously, the first data center acquired a connection to the destination object and acted as a proxy before the caller established its own direct connection. Now the first data center returns the destination directly so the caller can connect, removing the intermediate connection and duplicate acquisition. Cloudflare explicitly says no code or configuration changes are required.

Connection p99 is not whole-request latency

Cloudflare limits the potential benefit to p99 connection latency for relocation-related requests, with results depending on workload and traffic. The 99th percentile is a value at or below which roughly 99% of samples fall within a consistently defined sample set. It describes the slower tail; it is not an average.

Connection establishment is only part of a business call. Object execution, storage access and waits on external services can still affect the final response. Do not turn this routing improvement into a claim that every request, an entire website or every region becomes faster by the same proportion. The announcement provides no millisecond or percentage improvement that can be applied directly to your environment.

Why timing get() cannot validate the improvement

The namespace get(id) method returns a DurableObjectStub for calling the object. The official documentation says it returns immediately, often before a connection to the object has been established. Reading a clock before and after get(id) therefore primarily measures obtaining the calling handle; it does not establish whether this connection-path improvement took effect.

If you already have authorized call logs or monitoring, check the timing boundaries, sample window and workload before separating connection establishment from the whole business call. If you have only whole-call timing, report it under that definition. Independent connection timing or adequate samples may be unavailable; keep the result unknown. This is measurement advice, not a monitoring feature introduced by the announcement.

What should an existing application do?

This update does not require changing stub configuration, recreating objects or changing object IDs. Keep the existing calling pattern and record the actual problem and available evidence first. Avoid combining an investigation of routing gains with unrelated changes to retry counts, object identity or handling of business side effects.

Automatic retries decide which failed calls may be resent; this routing change alters the connection path after destination lookup. Assess them separately. For attempt limits, deadlines and idempotency boundaries, read: https://puppyip.com/en/resources/cloudflare-durable-objects-automatic-retry-guide .

For average origin latency in an API inventory, see: https://puppyip.com/en/resources/cloudflare-web-assets-metric-views-guide . That metric does not replace p99 connection latency here. This article explains the announcement and documentation; it does not benchmark your environment or announce a new regional guarantee.

Sources

Frequently Asked Questions

Does getByName(name) wait for a connection before returning?

No. The official namespace documentation also says getByName(name) returns a stub immediately, often before the connection exists. A fast return from that method alone does not establish the connection or business-call latency that follows.

Does the announcement provide a complete plan, price and country list?

No. It describes the routing change, the types of requests that may benefit, and the absence of required code or configuration changes. It does not list complete plans, fees, countries or per-account rollout times. It does not establish free access on every plan, identical results in every region or a change in account eligibility.