So, according to this, if I queued no-operation ``setTimeout``, I could prolong past the 10s?

So, according to this, if I queued no-operation

setTimeout

setTimeout

, I could prolong past the 10s?

AAries So, according to this, if I queued no-operation ``setTimeout``, I could prolong ...

Larry•10/23/25, 5:40 PM

Yes. That's one way people keep DOs alive. I think some people also use alarms. Not sure which is best.

TrueBrain•10/23/25, 6:06 PM

Is there a way to execute a worker from a DO where the walltime of this worker is not added to the walltime of the DO?

It might be a bit cheeky, but what I am trying to do:

Have a DO take care of administration for my users.
Once in a while (via alarms), the DO asks a worker to check in with an external API for an update.
This external API can be extremely slow. Think 10+ seconds to come up with an answer. As such, the worker returns a response near-instantly, while via
```
ctx.waitUntil
```
```
ctx.waitUntil
```
the external API fetch is finished, and a D1 table is updated.
This way the DO isn't blocked on the fetch for very long.

From a cost perspective, paying for 10s of walltime is ofc very expensive (especially as it is just waiting). So the idea of this setup was that the DO would run in short burst, and let the worker do the waiting on the external API.

However, and documentation suggests the same: Cloudflare is being nice (which I appreciate btw) and doesn't charge for the second worker invocation. But also adds the walltime of the second worker to the DO walltime. And I can't find a way for it to stop doing that

I tried several things:

Use service-bindings (works, but walltime is added together)
Use service-bindings and set smart placement on the worker (works, but DO now shows both requests in the GB-s graph, suggesting they are both billed under DO pricing)
Use direct HTTP (doesn't work, as you can't call a worker on your own account from another worker without a service-binding, it seems)

Any advise or best practice how to deal with DOs and fetches to external APIs that are very slow?

TTrueBrain Is there a way to execute a worker from a DO where the walltime of this worker i...

Hard@Work•10/23/25, 6:23 PM

DO invokes Worker via Service Binding, Service Binding returns after initiating work with

ctx.waitUntil()

ctx.waitUntil()

, allowing Durable Object to be evicted. Worker continues processing, and then once complete, uses the calling DOs ID to create a stub to it, and returns the response.

HHard@Work DO invokes Worker via Service Binding, Service Binding returns after initiating ...

TrueBrain•10/23/25, 6:24 PM

That is what I tried. But the walltime of the second worker is added to the DO, the dashboards tell me

TrueBrain•10/23/25, 6:26 PM

Basically I am trying to bypass https://developers.cloudflare.com/workers/platform/pricing/#service-bindings

But my experiements show for a DO it should read "walltime", not "CPU time"

TTrueBrain That is what I tried. But the walltime of the second worker is added to the DO, ...

Hard@Work•10/23/25, 6:26 PM

To confirm, the Worker immediately returns to the DO, right?

TrueBrain•10/23/25, 6:26 PM

Yes

Hard@Work•10/23/25, 6:26 PM

It doesn't do any work first?

TrueBrain•10/23/25, 6:27 PM

The DO object itself is also evicted in a few ms

TrueBrain•10/23/25, 6:28 PM

So from whatI can tell, everything is working exactly how you (and I) expect ... except for where the bill lands

TTrueBrain So from whatI can tell, everything is working exactly how you (and I) expect ......

Hard@Work•10/23/25, 6:29 PM

Just to confirm, does your bill reflect that, or is this only in the dashboard?

TrueBrain•10/23/25, 6:30 PM

Dashboard. The "Request Wall Time" of the DO, to be more exact.

TrueBrain•10/23/25, 6:31 PM

or "Billable Duration" for that matter

TrueBrain•10/23/25, 6:35 PM

No, I am wrong. The "Requests" and "Request Wall Time" combine both the DO and Worker. But "Billable Duration" appears to only account for DO walltime.
But the second workers dashboard only shows zeros, not even CPU time.

Now I am just confused

LLarry I find myself more and more optimizing my software design decisions based upon t...

gruntlord6•10/24/25, 12:56 AM

Had that with a value called redis , was painful to watch

Burrito•10/24/25, 2:27 AM

I've tried ORM, query builder, and raw SQL in various backend projects. They all have their issues, but nowadays I'm leaning more towards raw SQL end of the spectrum.

gruntlord6•10/24/25, 3:30 AM

Yea I started with an orm because a starter I was using had it pre configured but it was way more trouble then it was worth, especially because AI is very good at writing sql when you give it a spec

flof.fly•10/24/25, 12:54 PM

Hi I'm looking to use Cloudflare DO x Websockets, can anyone share their experience on reliability and scalability of it?

Fflof.fly Hi I'm looking to use Cloudflare DO x Websockets, can anyone share their experie...

Larry•10/24/25, 1:08 PM

The key is to assume the connection will break often and design for reconnection and resumability. If the server never needs to initiate communication, I use a lazy [re-]connection strategy where the next time the client needs to send something, it first checks if the connection is up and if not re-connects. For situations like chat where you need the server to reach out to the client, you will have to use the hooks for sensing when the connection is broken and reconect. There is a

reconnecting-websocket

reconnecting-websocket

package that Cloudflare Agents use for this purpose. I have forked that for my own purposes but you could just use that.

SH•10/24/25, 6:45 PM

Is there a way to register an unhandledrejection event handler in Durable Objects?

SSH Is there a way to register an unhandledrejection event handler in Durable Object...

Larry•10/24/25, 7:22 PM

What do you mean by "rejection"?

LLarry What do you mean by "rejection"?

SH•10/24/25, 7:43 PM

https://developers.cloudflare.com/workers/runtime-apis/web-standards/#unhandled-promise-rejections

Cloudflare Docs

Web standards

Standardized APIs for use by Workers running on Cloudflare's global network.

Larry•10/24/25, 11:08 PM

When I return a DO stub over Workers RPC, in vitest environment, the connection breaks unless I use setTimeout. Is this a known limitation of vitest, also what happens in prod, or am I just doing something wrong? I can share code if you like?

LLarry When I return a DO stub over Workers RPC, in vitest environment, the connection ...

1984 Ford Laser•10/24/25, 11:57 PM

Are you returning an

RpcTarget

RpcTarget

LLarry When I return a DO stub over Workers RPC, in vitest environment, the connection ...

1984 Ford Laser•10/25/25, 12:02 AM

Also for testing, is the DO class being returned in the same Worker? If not, you might need to run both Workers concurrently but I don't have much experience there

JJohn Spurlock now that DOs are on sqlite 3.47, any reason why the jsonb functions (https://sql...

John Spurlock•10/25/25, 9:43 PM

looks like JSONB support is now available in sqlite DOs, thanks so much to whoever made this change!

1984 Ford Laser•10/26/25, 11:32 PM

There needs to be a better way to track logs on a DO, especially when working with WebSockets. I have a DO that manages inbound (hibernated) sockets as well as multiple outgoing socket connections, as well as alarms and HTTP requests. Every WS message I receive I log, but those logs can be split between the different events that the DO manages. I can see the full list of logs for the current IOContext() of the outgoing sockets within the event invocation of the alarms, which feels very unintuitive. Should I be pushing the logs to observability or elsewhere instead of relying on the built-in logic?

Larry•10/27/25, 2:23 AM

I had a chance over the last week to do a deep dive on Cap'n Web. Here is my multi-page writeup as a comparison to my own Lumenize RPC. Please let me know what you think. I'm particularly interested in hearing if I've misconfigured anything on the Cap'n Web side which would explain some of the troubles I had: https://lumenize.com/docs/rpc/capn-web-comparison

vs Cap'n Web (summary) | Lumenize

Comparing Lumenize RPC to Cloudflare Cap'n Web

Larry•10/27/25, 1:57 PM

Is there a way for a DO instance to know what binding name was used to connect to it without explicitly passing that in? I know it's tricky with service bindings to it's not consistent so I'm guessing the answer is "no" but thought I'd ask.

LLarry Is there a way for a DO instance to know what binding name was used to connect t...

Hello, I’m Allie!•10/27/25, 2:16 PM

Not yet. The tricky part is that names aren’t bounded by size, so theoretically you could have a 50 MB name, which is not great to be shipping around the world. Though iirc the team is looking into supporting it somehow

ALECKS•10/27/25, 3:35 PM

I'm seeing some strange behavior after destroying a durable object.

I have this destory method():

async destroy() {
    // drop all tables
    this.sql`DROP TABLE IF EXISTS state`;
    this.sql`DROP TABLE IF EXISTS alarms`;
    this.sql`DROP TABLE IF EXISTS jobs`;

    // delete all alarms
    try {
      await this.ctx.storage.deleteAlarm();
      await this.ctx.storage.deleteAll();
      this.logger.info(`Destroying Durable Object ${this.ctx.id.toString()}`);
      this.logger.info(`Alarm: ${await this.ctx.storage.getAlarm()}`);
      this.ctx.abort("destroyed");
    } catch (_) {}
  }

async destroy() {
    // drop all tables
    this.sql`DROP TABLE IF EXISTS state`;
    this.sql`DROP TABLE IF EXISTS alarms`;
    this.sql`DROP TABLE IF EXISTS jobs`;

    // delete all alarms
    try {
      await this.ctx.storage.deleteAlarm();
      await this.ctx.storage.deleteAll();
      this.logger.info(`Destroying Durable Object ${this.ctx.id.toString()}`);
      this.logger.info(`Alarm: ${await this.ctx.storage.getAlarm()}`);
      this.ctx.abort("destroyed");
    } catch (_) {}
  }

When it executes, I see normal logs:

Destroying Durable Object 130f15d64c383661002b1c10796016628280fda1f20c1557eb8ff89543479444
Alarm: null 
✘ [ERROR] Uncaught Error: destroyed

Destroying Durable Object 130f15d64c383661002b1c10796016628280fda1f20c1557eb8ff89543479444
Alarm: null 
✘ [ERROR] Uncaught Error: destroyed

Then strangely, a few seconds later I see this:

Creating DO tables (alarms, jobs, state)   // this is logged from my DO's constructor
NOSENTRY SQLite alarm handler canceled with requestScheduledAlarm.; scheduledTime = 1761578532s; localAlarmState.orDefault(kj::UNIX_EPOCH) = 0ns; actorId = 130f15d64c383661002b1c10796016628280fda1f20c1557eb8ff89543479444

Creating DO tables (alarms, jobs, state)   // this is logged from my DO's constructor
NOSENTRY SQLite alarm handler canceled with requestScheduledAlarm.; scheduledTime = 1761578532s; localAlarmState.orDefault(kj::UNIX_EPOCH) = 0ns; actorId = 130f15d64c383661002b1c10796016628280fda1f20c1557eb8ff89543479444

After it's destroyed, something else wakes up the DO only to warn me that an alarm was replaced. Why is this happening?

ALECKS•10/27/25, 5:01 PM

Yes, the destroy() is called from within an alarm.. it's a sort of TTL where I tell the DO to destroy itself sometime in teh future. I do catch the exception thrown by abort() tho...

ALECKS•10/27/25, 5:02 PM

and the destory is working, i can see everything wiped in the sqlite file

ALECKS•10/27/25, 5:04 PM

that I don't know, just following code i saw in some examples

HHello, I’m Allie!Not yet. The tricky part is that names aren’t bounded by size, so theoretically ...

Larry•10/27/25, 5:11 PM

Thanks, while we're on the subject, is

ctx.id

ctx.id

always valid even when you got to the DO via

getByName()

getByName()

, meaning I can use it as a "return address" for in-Cloudflare communication even if my client-side application always uses the name?

LLarry Thanks, while we're on the subject, is `ctx.id` always valid even when you got t...

Hard@Work•10/27/25, 5:27 PM

It should be, since

getByName

getByName

is just a convenience utility mapping to

.get(DO.idFromName()

.get(DO.idFromName()

I think

LLarry Thanks, while we're on the subject, is `ctx.id` always valid even when you got t...

lambrospetrou•10/27/25, 5:45 PM

Yes, the ID is always populated and correct. And you can route to a DO by the ID even if other callers route by name.

Larry•10/27/25, 5:51 PM

I don't see a channel for Cloudflare Queues but please excuse me if this is the wrong channgel to ask on, but what's the expected latency for Cloudflare Queues between the time you push a message in and the time your Queue consumer is called?

LLarry I don't see a channel for Cloudflare Queues but please excuse me if this is the ...

Chaika•10/27/25, 6:00 PM

#queues

Chaika•10/27/25, 6:01 PM

it can def take a few seconds though How to make queues pick up messages

Larry•10/27/25, 6:28 PM

I am never sure I get the unit conversions correct. I've seen folks say it costs about $4/month to run a DO 24/7, but I've also seen $0.34/day which works out to about $10/month. Can someone show me the math?

LLarry I am never sure I get the unit conversions correct. I've seen folks say it costs...

lambrospetrou•10/27/25, 6:37 PM

1 DO running 24/7 needs:

0.128 GB-s * 3600 seconds_per_hour * 744 hours_in_month = 342_835 GB-s/month

0.128 GB-s * 3600 seconds_per_hour * 744 hours_in_month = 342_835 GB-s/month

and at the price

$12.50/million GB-s

$12.50/million GB-s

that's 4.285 USD/month (

342_835/1_000_000*12.50

342_835/1_000_000*12.50

).
You get 400,000 GB-s for free.

The above is duration only charges.

edit: using the correct

0.128 GB-s

0.128 GB-s

0.125GB-s

0.125GB-s

Larry•10/27/25, 6:38 PM

Thanks! I only need duration charge help. I can count requests, just not unit convert.

PhoenixSpace•10/27/25, 6:53 PM

Is there any way to get a hook to run code before a DO is evicted from memory? Would love to use it to flush in memory stuff to sql storage rather than needing to write a value that will be modified often in short bursts.

PPhoenixSpace Is there any way to get a hook to run code before a DO is evicted from memory? W...

Larry•10/27/25, 6:56 PM

There is no such hook and even if there were, it wouldn't always work because it can evicted for crazy reasons. The saving grace is that reading from and writing to storage is very fast due to caching and locality. I have switched to a coding style where I don't have instance variables unless the in-memory representation is an expensive transformation from the in-storage representation. It's counter-intuitive but think of storage like you used to think of instance variables.

Larry•10/27/25, 7:04 PM

For the cases where the in-memory transformation is expensive, I have also adopted a coding style where I save and retrieve that largish structure in one whole shot using the fact that the KV API let's you store just about everything (objects with cycles or aliases, Date, Map, Set, Infinity, NaN, etc.). See the complete list in the second column here

LLarry There is no such hook and even if there were, it wouldn't always work because it...

PhoenixSpace•10/27/25, 7:05 PM

That's pretty fair, wishful thinking I guess. Wanted to avoid the $1/million write charges because it's an extremely bursty workflow (counting a rapid stream of events), but honestly not that bad

PhoenixSpace•10/27/25, 7:05 PM

the storage backend KV-like API for sqlite is OP though

Larry•10/27/25, 7:08 PM

Reads are so inexpensive I ignore the cost. Write costs can add up.

PhoenixSpace•10/27/25, 7:08 PM

Yup, that's why I was wondering if I could just flush it with a handle

async destroy() { // drop all tables this.sql`DROP TABLE IF EXISTS state`; this.sql`DROP TABLE IF EXISTS alarms`; this.sql`DROP TABLE IF EXISTS jobs`; // delete all alarms try { await this.ctx.storage.deleteAlarm(); await this.ctx.storage.deleteAll(); this.logger.info(`Destroying Durable Object ${this.ctx.id.toString()}`); this.logger.info(`Alarm: ${await this.ctx.storage.getAlarm()}`); this.ctx.abort("destroyed"); } catch (_) {} }

Creating DO tables (alarms, jobs, state) // this is logged from my DO's constructor NOSENTRY SQLite alarm handler canceled with requestScheduledAlarm.; scheduledTime = 1761578532s; localAlarmState.orDefault(kj::UNIX_EPOCH) = 0ns; actorId = 130f15d64c383661002b1c10796016628280fda1f20c1557eb8ff89543479444