Why hard spending caps take time: Ashley Peacock on billing latency
Ashley Peacock (@ashleypeacock), who works on Durable Objects at Cloudflare, explains from experience why near-real-time spending caps are hard to build, says hard billing caps are coming soon, and suggests budget alerts plus issue alerts in the meantime.
- Products
- Account-wide usage-based productsDurable Objects
- Source
- Author experience𝕏
- Author
- Ashley Peacock (@ashleypeacock)
Key points
- The author says he does not work on spending caps directly and speaks from experience plus a little of what he has seen internally.
- He describes billing as typically an OLAP workload: at AWS, the last time he checked, current-day spend appears only after an overnight job writes the figures the next day, which he calls the norm for many services at scale.
- Spending caps, he writes, need near-real-time data and OLTP-level support; Cloudflare’s developer platform spans many products, so billing has to migrate and decide how and where to cap. He says the work has been in progress but is not a quick win.
- Cloudflare’s current Budget alerts documentation says alerts email recipients once per billing period when account-wide usage-based spend crosses the threshold, and that they do not pause or cap usage.
Original sources
Original source · Published
Read on 𝕏Ashley Peacock
@ashleypeacock · Original 𝕏 post
I’m not directly working on it, so I can only speak from experience + a little of what I’ve seen internally Billing is typically an OLAP workload, if you look at AWS (last time I checked), you can’t see what you’ve spent on the current day until the next day when an overnight…
In another reply under @shmily7’s thread, the author writes that hard billing caps are coming soon and that he is looking at what more can be done on the Durable Objects side, which is not straightforward because legitimate use cases must be accounted for.
Read on 𝕏Ashley Peacock
@ashleypeacock · Original 𝕏 post
Hard billing caps are coming soon, and I’m seeing if there’s more we can do on the DO side but it’s not straightforward to solve (e.g. there are legitimate use cases we need to account for)
Replying to a user, the author suggests a budget alert as a starting point, says a hard cap will be available in the near future, and suggests sending Workers issue detection to coding agents or Slack. He adds that such incidents are rare and the team is working to reduce them.
Read on 𝕏Ashley Peacock
@ashleypeacock · Original 𝕏 post
I would set a budget alert: https://t.co/ySrAx2jq5H as a starting point, you’ll be able to set a hard cap in the near future too. You can also hook https://t.co/z5u5q4JGOb up to your coding agents, so any anomalies or issues spotted get sent to them (or get a Slack message or…
Replying to a developer who says many small developers would rather have a hard budget cap that stops the service, the author writes that caps are coming very soon.
Read on 𝕏Ashley Peacock
@ashleypeacock · Original 𝕏 post
They are coming very soon
More to read
Idle projects can still bill: check background tasks and storage
@An_yhl reads @shmily7’s follow-up as a reason to audit abandoned AI projects: check scheduled background work and storage reads and writes, stop what is unused instead of just closing the page, and turn on alerts knowing they will not stop anything.
shmily7: a Durable Object alarm loop and a reported US$10,811.41 bill.
@shmily7 reports a Durable Object alarm loop in an unused test project, then says he paid the full US$10,811.41 bill to avoid service suspension. Cloudflare’s Ashley Peacock publicly says he is looking into it internally and will follow up. Cloudflare’s Dane Knecht later replies that he escalated it too. On October 9 the author declares the case closed: he reports that, with Ashley Peacock’s help, Cloudflare decided to refund the charges incurred during the bug in full, with the money still to arrive, and posts the support ticket reply he received.
Removing unneeded Durable Objects from MCP servers on Workers
Justin (@interjc) describes moving read-only MCP servers from McpAgent, which starts a Durable Object per session, to stateless createMcpHandler, and shares a prompt for auditing Workers bindings and runaway usage patterns.