耐用对象警报循环:8天内收入34,000美元,用户为零,没有平台警告。
分享这个内容是为了警告任何使用 Cloudflare Durable Objects(持久对象)和警报的用户。
<p>根本原因:</p>
我的 DO 代理的 onStart() 处理程序在每次唤醒时都调用了 this.ctx.storage.setAlarm(),而没有检查是否已经安排了一个警报。加上 60 多个预览 Worker 部署,每个都创建了独立的 DO 实例,这导致了一个失控的自我健康检查循环。
<p>时间线:</p>
- 4 月 3 日:循环开始(在此日期之前没有 DO 使用)
- 4 月 4-5 日:达到约 9300 亿行读取/天的峰值
- 4 月 11 日:发现问题并修复
- 4 月 15 日:收到 34,895 美元的账单,但尚未收到任何账单回应
<p>修复方法:</p>
```javascript
// 修复前(危险)
async onStart() {
await this.ctx.storage.setAlarm(Date.now() + 60_000)
}
// 修复后(安全)
async onStart() {
const existing = await this.ctx.storage.getAlarm()
if (!existing) {
await this.ctx.storage.setAlarm(Date.now() + 60_000)
}
}
```
<p>值得做的其他事情:</p>
- 完全从预览环境中移除 DO 绑定
- 部署一个预算监控的杀死开关 Worker
- 添加一个电路断路器,在调度之前检查警报状态
<p>为什么我没有收到警告:</p>
Cloudflare 的 Workers 使用通知仅监控 CPU 时间,而不监控 Durable Object 的行读取或写入。仪表板或 Wrangler 配置中也没有可用的 DO 操作硬性支出上限。在这个失控的过程中,没有任何东西会触发警报。我是在账单出现时才发现的。
<p>如果你在使用 DO 警报,这一点值得知道。平台不会告诉你 DO 行读取/写入何时呈指数增长。你必须自己建立一个杀死开关。</p>
<p>还有一件我认为值得更多关注的事情:这是代理周。Cloudflare 目前正在进行专门的营销推广,鼓励个人开发者在 Durable Objects 上构建 AI 代理。博客文章、公告,所有的一切。这是一个有意的努力,旨在将独立开发者和独立创始人引入一个可以在没有任何平台警告的情况下悄然产生五位数账单的产品。DO 操作没有支出上限。使用通知系统不涵盖 DO 的读取或写入。Cloudflare 知道这一点。在这个缺口存在的情况下进行代理周的决策并不是中立的。</p>
我已经提交了案例 02067725。我是一名预发布的独资经营者,将我所有的个人储蓄投入到这个初创公司中。这张账单将会在没有任何商业价值的使用情况下摧毁我的财务。在这里分享既是技术警告,也是因为我需要帮助将此问题呈现给 Cloudflare 的某个可以做出决策的人。
有没有人成功升级过与 Cloudflare 的账单争议?
查看原文
Sharing this as a warning to anyone using Cloudflare Durable Objects with alarms.<p>Root cause:<p>My DO agent's onStart() handler called this.ctx.storage.setAlarm() on every wake-up without checking whether an alarm was already scheduled. Combined with 60+ preview Worker deployments each creating independent DO instances, this created a runaway self-health-check loop.<p>Timeline:
- April 3: loop began (zero DO usage before this date)<p>- April 4-5: peaked at ~930 billion row reads/day<p>- April 11: found it, fixed it<p>- April 15: $34,895 invoice due with no billing response yet<p>The fix:<p>// Before (dangerous)
async onStart() {
await this.ctx.storage.setAlarm(Date.now() + 60_000)
}<p>// After (safe)
async onStart() {
const existing = await this.ctx.storage.getAlarm()
if (!existing) {
await this.ctx.storage.setAlarm(Date.now() + 60_000)
}
}<p>Other things worth doing:
- Strip DO bindings from preview environments entirely
- Deploy a budget monitor kill switch Worker
- Add a circuit breaker that checks alarm state before scheduling<p>Why I had no warning:<p>Cloudflare's Workers Usage Notifications only monitors CPU time. Not Durable Object row reads or writes. There is also no hard spending cap for DO operations available in the dashboard or Wrangler config. Nothing would have fired an alert during this runaway. I found out when the bill showed up.<p>This is worth knowing if you're using DO alarms. The platform will not tell you when DO row reads/writes go exponential. You have to build your own kill switch.<p>One more thing that I think deserves more attention than it's getting: this is Agents Week. Cloudflare is running a dedicated marketing push right now to get individual developers building AI agents on Durable Objects. Blog posts, announcements, the whole thing. That is a deliberate effort to onboard solo developers and indie founders into a product that can silently generate a five-figure bill with zero platform warning. There is no spending cap for DO operations. The usage notification system doesn't cover DO reads or writes. Cloudflare knows this. Running Agents Week while that gap exists is not a neutral decision.<p>I've filed Case 02067725. I'm a pre-launch sole proprietor who put all my personal savings into this startup. This bill would financially destroy me for usage that generated zero business value. Sharing here both as a technical warning and because I need help getting this in front of someone at Cloudflare who can make a decision.<p>Has anyone escalated a billing dispute with Cloudflare successfully?