{
  "version": "2",
  "id": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86",
  "title": "Cloudflare Durable Objects Can Now Keep Running Without a Connected Client",
  "summary": "A new default for Workers with a compatibility date of 2026-10-01 or later keeps Durable Objects alive while service bindings, RPC calls, container monitors, waitUntil promises and timers are pending, with a 15-minute cap per operation.",
  "body": "Cloudflare has changed how Durable Objects behave when no client is connected. According to the company's changelog, pending I/O operations now keep a Durable Object running instead of allowing it to be shut down as idle. The change is aimed at workloads that outlive the request that started them, such as an agent that continues a submitted job after its client disconnects.\n\nThe mechanism is a set of operations that Cloudflare now treats as evidence of ongoing work. Pending service binding requests keep a Durable Object alive while they wait for a response. So do pending calls to another Durable Object made through remote procedure call or fetch(), and calls to this.ctx.container.monitor(). Promises handed to this.ctx.waitUntil(), along with pending setTimeout() and setInterval() timers, receive the same protection.\n\nCloudflare describes the previous behaviour as a risk to unfinished work. Before this change, the platform could shut down an idle Durable Object while one of those operations was still pending and no client was connected, which could stop work that had not completed. The new behaviour is intended to let long-running tasks such as agents proceed without depending on the original client staying connected.\n\nThis protection does not cover every type of pending work as a new concept. According to Cloudflare, Durable Objects were already kept running by TCP sockets, outbound WebSockets, and outbound fetch() requests to external services. Rather than introducing the concept from scratch, the changelog extends an existing principle to service bindings, RPC, container monitoring, waitUntil promises and timers.\n\nCompatibility date controls the rollout. The behaviour is the default for Workers whose compatibility date is 2026-10-01 or later. By adding the durable_object_io_tasks_prevent_eviction compatibility flag, projects on an earlier compatibility date can opt in. With the durable_object_io_tasks_do_not_prevent_eviction flag, projects that want the old behaviour can opt out.\n\nA documented ceiling exists on how long any single operation can hold a Durable Object in memory. Idle shutdown is prevented by each pending operation for up to 15 minutes. The object's time in memory can be extended if another operation starts later, and Cloudflare notes that the limit applies per operation rather than to the total time the object spends in memory.\n\nCost is not suspended along with eviction. Cloudflare states that duration charges continue while an operation prevents eviction. For developers running agents or background jobs, that means the reliability gain comes with a billing consequence: an object kept alive by a pending call is still accruing duration charges during that window.\n\nThe practical effect for freelancers and small studios is that agent-style and job-style workloads become less dependent on a browser tab or client connection staying open. A submitted job can continue through a service binding, coordinate with another Durable Object, or wait on a container process after the originating client disconnects, which is the scenario Cloudflare uses to frame the change.\n\nThe tradeoff is predictability of spend. Because each pending operation can hold an object for up to 15 minutes and duration charges continue, a chain of operations that repeatedly starts new pending work can keep an object resident for longer than a developer might expect from an idle-shutdown model. The per-operation limit means the ceiling is not a single 15-minute lifetime cap for the object.\n\nThe changelog does not describe pricing changes, new limits on the number of concurrent pending operations, or any change to how duration is metered beyond confirming that charges continue. It also does not state whether the 15-minute window is measured or enforced differently across operation types, and it does not provide migration guidance beyond the two compatibility flags.\n\nFor teams already on a compatibility date at or after 2026-10-01, the change arrives without code edits, which means existing assumptions about idle shutdown may no longer hold. Teams that rely on eviction to bound cost or to reset in-memory state should review whether the opt-out flag is appropriate for them.\n\nTeams on earlier compatibility dates face a deliberate choice. Adding durable_object_io_tasks_prevent_eviction brings the new behaviour to existing projects, while durable_object_io_tasks_do_not_prevent_eviction preserves the previous shutdown behaviour. Because the two flags point in opposite directions, the decision is effectively about whether unfinished background work or predictable eviction matters more for a given workload.\n\nThe change fits a broader pattern in which serverless platforms are asked to support work that is not tied to a single request-response cycle. Cloudflare's own framing is that this helps run long-running tasks such as agents, and the listed mechanisms — service bindings, RPC, container monitoring, waitUntil and timers — map onto the building blocks an agent or job runner would use.\n\nWhat remains unknown from the supplied material is how the change interacts with existing Durable Object lifecycle documentation, which Cloudflare points readers to for more information. The changelog does not quantify how often idle shutdown previously interrupted pending work, nor does it offer benchmarks or examples of the new behaviour under load.\n\nFor a working developer, the immediate action is to check the compatibility date on each Worker that uses Durable Objects and decide whether to adopt, opt in or opt out. The second action is to revisit cost expectations for any workload that now stays resident while waiting on bindings, RPC, containers, waitUntil promises or timers.\n\nThe headline fact is narrow and verifiable: pending I/O operations now prevent idle shutdown of Durable Objects, the behaviour is default from compatibility date 2026-10-01, two flags control it, each operation protects for up to 15 minutes, and duration charges continue. Everything beyond that — how much this saves in failed jobs, or what it costs in extra duration — is not established by the source.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-10-05T12:18:31.927Z",
  "dateModified": "2026-10-05T12:18:31.927Z",
  "eventDate": "2026-10-01",
  "sourcePublicationDate": "2026-10-01T00:00:00.000Z",
  "source": {
    "name": "developers.cloudflare.com",
    "url": "https://developers.cloudflare.com/changelog/post/2026-10-01-pending-io-keep-alive/",
    "kind": "official-publisher"
  },
  "practicalImpact": "Editorial interpretation: developers running agent or background-job workloads on Durable Objects should check each Worker's compatibility date and decide whether the new default, the opt-in flag or the opt-out flag matches their cost and state-reset expectations, since objects can now stay resident — and billable — while waiting on bindings, RPC, containers, waitUntil promises or timers.",
  "limitations": "The changelog does not state pricing changes, concurrency limits on pending operations, how the 15-minute window is measured across operation types, or migration guidance beyond the two compatibility flags. It provides no benchmarks or frequency data for how often idle shutdown previously interrupted pending work. No independent testing is claimed.",
  "keyPoints": [
    "Pending service binding requests, RPC or fetch() calls to other Durable Objects, this.ctx.container.monitor(), waitUntil promises and setTimeout()/setInterval() timers now keep a Durable Object running without a connected client.",
    "The behaviour is the default for Workers with a compatibility date of 2026-10-01 or later; earlier projects can opt in with durable_object_io_tasks_prevent_eviction or opt out with durable_object_io_tasks_do_not_prevent_eviction.",
    "Each pending operation prevents idle shutdown for up to 15 minutes, and the limit applies per operation rather than to total time in memory.",
    "Duration charges continue while an operation prevents eviction.",
    "Outbound fetch() to external services, TCP sockets and outbound WebSockets already kept Durable Objects running before this change."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-10-05T12:18:31.927Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://developers.cloudflare.com/changelog/post/2026-10-01-pending-io-keep-alive/",
      "publisher": "developers.cloudflare.com",
      "title": "Changelog",
      "publishedAt": 1790812800000,
      "fetchedAt": 1791202698700,
      "hash": "579115c14792fd78f30585063edbf52d3e838460231ac99b985903d5d4ec218c",
      "kind": "official-publisher"
    }
  ],
  "claims": [
    {
      "claim": "Pending service binding requests, RPC or fetch() calls to another Durable Object, and this.ctx.container.monitor() now keep a Durable Object running.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86#claim-1"
    },
    {
      "claim": "Promises passed to this.ctx.waitUntil() and pending setTimeout() and setInterval() timers also receive this protection.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86#claim-2"
    },
    {
      "claim": "The behaviour is default for Workers with a compatibility date of 2026-10-01 or later, with flags to opt in or out for earlier dates.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86#claim-3"
    },
    {
      "claim": "Each pending operation prevents idle shutdown for up to 15 minutes, and the limit applies per operation rather than to total time in memory.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86#claim-4"
    },
    {
      "claim": "Duration charges continue while an operation prevents eviction.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86#claim-5"
    },
    {
      "claim": "Outbound fetch() requests to external services, TCP sockets and outbound WebSockets already kept Durable Objects running.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86#claim-6"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86",
    "markdown": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86.md",
    "json": "https://freelancenews.online/news/cloudflare-durable-objects-can-now-keep-running-without-a-connected-ff0e1f86.json"
  }
}