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
- The change covers in-flight requests and connections during Workers runtime updates, including HTTP streams and WebSockets.
- The limit applies to each old runtime process; unfinished work ends when its grace period expires.
- WebSockets can disconnect earlier, including connections using the Hibernation API. Reconnect, retry safely and restore saved state.
- CPU budgets, post-response waitUntil() time and user code deployments follow their own rules.
Whose 20-minute clock is it?
Cloudflare's October 12 announcement extends the runtime-update grace period from up to 30 seconds to up to 20 minutes. The runtime is the platform process that executes your Worker. Longer HTTP requests, streamed AI responses and live WebSockets gain more room to finish.
Once the updated runtime is ready, new HTTP requests move to it. Old processes stop accepting those requests and drain existing work. Each old process has its own grace period, after which unfinished requests and connections terminate.
A request does not receive a fresh 20 minutes when it starts. The clock belongs to the old runtime process, rather than restarting for each request; crashes, resource pressure or shutdowns can interrupt it sooner. The announcement gives no per-account activation time or configuration switch to enable.
A stream can finish more often, but still needs recovery
Imagine an AI response is halfway through streaming when its runtime enters the grace period. More time improves its opportunity to finish, without guaranteeing delivery of the final chunk. This is a design example; PuppyIP has not run an account Worker or tested this change.
The client should distinguish a completed response, an interrupted connection and an unknown request outcome. Partial text alone is not a completion signal. Keep a request identifier, confirmed progress and final status so recovery can pick up the right work.
For requests that write data, charge money or send messages, check the outcome before resending. Safe retries need idempotency: repeating an operation should not repeat its business effect. A longer client timeout cannot provide that protection.
Reconnect the WebSocket, then restore the session
The announcement calls for reconnection handling and says WebSockets may close before the grace period ends, including Hibernation API connections. Hibernation lets a Durable Object release memory under suitable conditions while retaining connections; it does not promise an unbroken connection.
Handle close and error events with backoff, then reauthenticate, restore subscriptions and resume from the last acknowledged message. These are implementation recommendations. Your application defines the retry interval and recovery protocol; the announcement supplies no universal values.
Keep essential progress beyond memory and connection attachments. The Durable Objects guide says serializeAttachment() survives hibernation but loses its data when the connection closes. Data that must outlive the connection belongs in durable storage.
Check four different time limits separately
Runtime grace and CPU time measure different things. CPU time counts active code execution, generally excluding network waits. The extension does not create a 20-minute CPU allowance or remove plan, memory or request limits. The announcement introduces no new price or separate charge.
HTTP-triggered Workers have no general hard duration limit while the client stays connected, subject to updates and resource limits. After a response or disconnection, ctx.waitUntil() can continue for up to 30 seconds. The new grace period does not extend that allowance to 20 minutes.
Deploying your own code is another case. The Durable Objects WebSocket guide says code updates restart objects and disconnect existing connections. Platform runtime grace is not a promise that every application deployment preserves them.
Which recovery paths should you check first?
First, inventory long HTTP streams, WebSockets and requests with side effects. Identify the completion signal and where acknowledged progress lives. A log saying the connection opened does not establish that the task finished.
Next, simulate interruptions in your own isolated test environment. Check reconnection, duplicate-request protection and state restoration. Confirm that resumed work continues without duplicate writes. These are suggested checks, not tests performed by PuppyIP.
Finally, correlate close reasons, request outcomes and resource errors in your logs. Treat the extra time as recovery room while keeping failure handling. One long-lived connection cannot establish an availability guarantee or a production uptime rate.
Sources
Frequently Asked Questions
Should I change compatibility_date to October 12?
The announcement requires no compatibility_date change or compatibility flag. It describes platform runtime-update grace, so do not invent a configuration to enable it. Manage existing compatibility settings under their own documentation.
Does a disconnection prove a runtime update caused it?
No. Clients, networks, application deployments and resource limits can also interrupt connections. Correlate your logs and close reasons with platform information rather than attributing the cause from timing alone.
How much will my failure rate improve?
The announcement supplies no application-specific success-rate data. Evaluate completion, reconnection and recovery over a defined observation window and sample. A longer grace period cannot by itself establish an availability percentage.