HackerNews中文版

分享此内容，旨在警告所有使用 Cloudflare Durable Objects 和警报功能的用户。根本原因：我的 DO 代理的 onStart() 处理器在每次唤醒时都调用了 this.ctx.storage.setAlarm()，而没有检查是否已经安排了警报。再加上 60 多个预览版 Worker 部署，每个部署都创建了独立的 DO 实例，这导致了一个失控的自我健康检查循环。时间线： - 4 月 3 日：循环开始（在此日期之前 DO 使用量为零）- 4 月 4-5 日：达到峰值，约 9300 亿行读取/天- 4 月 11 日：发现问题，修复- 4 月 15 日：账单 34,895 美元到期，尚未收到账单回复修复方法：// 之前（危险） 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) } }其他值得做的事情： - 完全从预览环境中移除 DO 绑定 - 部署一个预算监控杀手开关 Worker - 添加一个断路器，在安排警报之前检查警报状态为什么我没有收到警告：Cloudflare 的 Workers 使用通知仅监控 CPU 时间。不监控 Durable Object 的行读取或写入。仪表板或 Wrangler 配置中也没有 DO 操作的硬性支出上限。在这个失控的过程中，没有任何东西会触发警报。我是看到账单后才知道的。如果您正在使用 DO 警报，这一点非常重要。平台不会告诉您 DO 行读取/写入呈指数级增长。您必须构建自己的杀手开关。还有一件事，我认为它比现在得到的关注更多：这是 Agents Week。Cloudflare 目前正在进行专门的营销推广，以吸引个人开发人员在 Durable Objects 上构建 AI 代理。博客文章、公告，等等。这是一个有意的努力，旨在引导独立开发人员和独立创始人进入一个可以默默地生成五位数账单且没有任何平台警告的产品。DO 操作没有支出上限。使用通知系统不涵盖 DO 读取或写入。Cloudflare 知道这一点。在存在这种差距的情况下运行 Agents Week 并不是一个中立的决定。我已经提交了案例 02067725。我是一个预发布阶段的独资经营者，把所有的个人积蓄都投入到这家初创公司。这笔账单会因为没有产生任何业务价值的使用而让我破产。在这里分享，既是一个技术警告，也是因为我需要帮助，以便让 Cloudflare 的某个人能够做出决定。有人成功升级了与 Cloudflare 的账单争议吗？

查看原文

Sharing this as a warning to anyone using Cloudflare Durable Objects with alarms.Root cause: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.Timeline: - April 3: loop began (zero DO usage before this date)- April 4-5: peaked at ~930 billion row reads/day- April 11: found it, fixed it- April 15: $34,895 invoice due with no billing response yetThe fix:// Before (dangerous) async onStart() { await this.ctx.storage.setAlarm(Date.now() + 60_000) }// After (safe) async onStart() { const existing = await this.ctx.storage.getAlarm() if (!existing) { await this.ctx.storage.setAlarm(Date.now() + 60_000) } }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 schedulingWhy I had no warning: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.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.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.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.Has anyone escalated a billing dispute with Cloudflare successfully?

持久对象报警循环：8天内消耗3.4万美元，零用户，无平台警告