Refunds are not a safety net: install your own brakes on cloud bills

Key points

• The author opens with the shmily7 Durable Objects alarm case: a test project with no users whose alarm callback rescheduled itself about 600 times per second. For products billed by invocations or rows read and written, he argues, the bill depends only on how many times the code runs, not on whether anyone uses it, and AI-written code that works and passes tests may never have been asked how often it runs in the worst case or when it stops.
• He treats refunds as a lottery rather than a fallback: outcomes for similar incidents range from nearly full refunds to outright refusal, refunds are often account credit rather than money back to the card, bills keep rising for a while after services are shut down because billing lags and queued work keeps running, and a platform can demand payment before it stops suspending the account. His conclusion is to count refunds as zero when planning for risk.
• He stresses that budget alerts only send email and do not stop anything. In his table (as of 2026-10-15), Cloudflare has no cap that stops service; the options he lists are lowering the per-invocation CPU limit (which only bounds a single invocation, not the total), setting a separate spend limit in AI Gateway, and deleting unused Workers and Durable Objects. He also compares the stopping caps of Vercel, Supabase, OpenAI and Gemini and the cost each imposes when it triggers.
• His five steps: put a low-limit virtual card on cloud services (a declined card does not erase the debt and the account may still be suspended, but it blocks the first automatic charge); turn on every existing hard cap and confirm it really stops; add stop conditions to everything that runs by itself (crons, queues, alarms, webhook retries, AI agents) and delete unused test projects; keep keys server-side, one per project, with per-user limits on expensive endpoints; and do not keep everything in one account.
• For Durable Objects he gives a prompt to hand to an AI coding tool: list every alarm, Cron Trigger and Queue consumer that reschedules itself and its stop condition; check getAlarm() before setting an alarm; stop and log after N consecutive runs; never bind production Durable Objects to preview environments; and also look for full table scans in database queries.
• If it has already happened, his order is: stop first (pause deployments, remove Worker triggers, disable or rotate keys), expect the bill to keep rising briefly, screenshot usage graphs, bills and timestamps, then appeal by stating what happened, how you stopped it and how you will prevent it, asking for a one-time waiver, and asking whether any refund is cash or account credit. He packaged the checks as a YouMind Skill, “云服务防背刺体检”.
• Official docs (rechecked 2026-10-16): budget alerts are informational only and do not pause or cap usage.

Original sources

1. Published2026-10-15

   Original post

   Read on 𝕏

   SagaSu (@sujingshen) writes a loss-control guide for indie developers: usage-billed code can burn money with zero users, refunds should be planned as zero, and budget alerts are not brakes; it lists five things to set up beforehand and what to do once a bill has already spiked.

   SagaSu

   @sujingshen · Original 𝕏 post

   https://t.co/pVWwTTMRhY

   2026-10-15 13:19:01 UTC

   Read originalArchived 2026-10-16

   SagaSu · @sujingshen

   This archive does not contain the complete text.

   别被云服务背刺：退款不是安全网，刹车得自己装

   独立开发者的账单与账号止损指南 by Sagasu · 2026 年 10 月 2026 年 10 月，Cloudflare 上有个开发者 shmily7 收到一张 $10,811.41 的账单。出事的项目是个没在用的测试项目，没有一个用户，代码是 AI 帮着写的。Durable Objects 的 alarm 回调里有一行在给自己重新定时，每秒大约触发 600 次。 他做的第一件事是把钱全额付掉，因为不付账号就可能被停，账号下面还挂着别的服务。客服先是拒绝，后来 Cloudflare 有员工看到帖子出面，10 月 9 日处理了 $10,701.41 的退款，比账单少 $110。他公开更新这个消息时，钱还没到账。 这一件事里，其实已经能看出独立开发者被云服务「背刺」的全部要素：没人用也能烧钱；平台不会替你踩刹车；退款要靠运气；而平台手里同时握着你的账单和你的服务。 一、没人用，也能烧钱 以前大家怕的是突然火了、流量爆了、账单跟着爆。现在不用火，部署上去就可能出事。 算一下 shmily7 那个循环：每秒 600 次，一天就是 5,184 万次调用，而且是没有人访问的情况下。按次数、读写行数计费的产品，账单只取决于代码跑了多少次，和有没有人在用无关。 Billflare 专门收集这类事故。它的 Durable Objects 专题里有 13 起，报告金额合计 $66,897.60。最大的一起是 Will Moss 的 $34,895：健康检查会唤醒对象，对象一醒就重设 alarm，前后约 20 万亿次读取，他还因此失去了项目的访问权限。另有一起是队列消费者循环，账单约 $36,000。剩下的大多几百到几千美元，原因高度重复：alarm 自己调度自己、重试没有上限、D1 查询没建索引反复全表扫描（zmuleyu 一次读了 1.476 万亿行）。 好几起明确写着代码是 AI 写的。这不是在怪 AI。AI 写出来的代码功能是对的，测试也能过，只是从来没人问过它一句：「这段代码最坏情况下每分钟会跑多少次？什么时候会停？」不写代码的人自己想不到问，AI 也不会主动说。 二、退款是彩票，不是安全网 很多教程最后一步写的是「联系客服申请减免」，好像这是一条可靠的退路。看一下同一个平台、同一类事故的结果： 从接近全额到直接拒绝都有。几起结果好的，基本都是在 X 上发了帖、有员工或高管看到后出面的。Netlify 那张 $104,500 的账单也是舆论发酵之后才免掉的。 有三个细节比「能不能退」更值得记住。 退款常常是账户信用，不是退回卡里。 钱回不到你手上，只能继续在这个平台上花。 关掉服务，账单不会马上停。 计费有延迟，排队中的任务还在跑。babynarc 关掉之后，账单从 $300 涨到了 $500。 平台可以拿停服来要求你先付钱。 对一个所有东西都放在一个账号里的人来说，这几乎不是选择题。 所以做风险规划时，退款要按 0 算。能保护你的只有出事之前就生效的刹车。 三、每家的刹车装在不同地方，踩下去都会疼 「预算提醒」是最常见的误会。Lion Brain 那起 $210 的事故，就是靠预算提醒邮件才发现的；Google Cloud 上有人设了 $10 预算提醒，照样被刷到 $1,300。提醒只发邮件，不会停服。 真正会停的刹车，各家现在是这样的（截至 2026-10-15）： 每一个刹车都有代价：Vercel 会让网站下线，Gemini 会把你所有项目一起拖停，Supabase 会让服务报错。但个人项目的账很好算：网站挂一天，丢几个访客；账单爆一晚，可能是一年的收入。有刹车的地方全部打开，代价你自己接住。 四、真正要做的只有五件事 1. 给云服务绑一张低额度虚拟卡。 这是唯一在所有平台上都起作用的刹车，也是 Cloudflare 现在唯一的刹车。需要说清楚的是：卡刷不过，欠款并不会消失，账号也可能因为欠费被停。但它能挡住第一时间的自动扣款，给你留出止损、申诉的时间，不至于一觉醒来卡里的钱已经没了。 2. 把已有的硬上限全部打开，并确认它真的会停。 Vercel 去 Settings → Billing → Spend Management，设金额，确认 Pause production deployments 开着（新项目默认开，老项目自己查）。Supabase 去 Organization → Billing 确认 Spend Cap 开着，不用的项目直接删。OpenAI 给每个项目设上限。Gemini 在 AI Studio 的 Spend 页面给每个项目设月度上限；重要项目最好单独用一个结算账户，免得别的项目把它一起拖停。 3. 给每一个会自己跑的东西加停止条件，用不到的测试项目直接删。 Cron、队列、alarm、Webhook 重试、AI Agent 都算。不写代码的话，把相关代码交给你的 AI 编程工具，用这段话让它查： 检查这个项目里所有 Durable Objects 的 alarm、Cron Trigger、Queue 消费者。列出每一处「会再次调度自己」的地方，说明它在什么条件下停止。如果没有明确的停止条件、最大次数或最大运行时长，请加上：设 alarm 之前先用 getAlarm() 检查是否已有；连续执行超过 N 次就停止并记录日志；预览环境不能绑定生产环境的 Durable Objects。只改这些，不动其他逻辑。 别的平台把第一句里的名词换掉就能用。数据库查询也让它顺便查一遍有没有全表扫描。 4. Key 只放在服务端，每个项目一把，贵的接口按用户限次。 Gemini 有一起 Key 被盗，48 小时 $82,000；还有学生把 Key 提交到 GitHub，收到 $55,444.78。公开仓库几分钟内就会被机器人扫到，所以 Key 绝不进前端、绝不进 GitHub，仓库打开 Secret Scanning。生图这类按张收费的接口，给每个用户设每天上限。同一类问题还有 Supabase 的 RLS：Lovable 生成的 170 多个应用没配好行级权限，数据谁都能读（CVE-2025-48757）。让 AI 写一个「未登录读取每张表」的测试，确认什么都读不到；Service Role Key 永远不出现在前端。 5. 别把所有东西放在一个账号里。 这条针对的是账号被停、资金被冻。有团队被 Cloudflare 要求短期内签约约 12 万美元/年的 Enterprise，不签就下线，最后网站真的被下线了；有人 Hetzner 账户被删，服务器和数据一起没了。最少要做到三点：数据库定期导出到另一家公司，并且亲手恢复过一次；域名和 DNS 不和主机放在同一个账号；第二个收款渠道（Paddle、Lemon Squeezy、PayPal 之一）提前注册好。用 Stripe 的再加一条：支付页加验证码，在 Radar 里限制同一张卡、同一个 IP 的尝试次数，防盗卡测试。 五、已经出事了：先停，再截图，再申诉 先停再查。 暂停部署、删掉 Worker 的触发器、停用 Key。怀疑泄露就吊销重建，不是改名。 停了还涨是正常的。 计费有延迟，越早停越少。 截图。 用量曲线、账单、时间点，申诉时全靠这些。 申诉写清楚三件事：发生了什么、你已经怎么止损、以后怎么防，请求一次性减免。工单没人回，就在 X 上礼貌地公开说明情况。 问清楚退的是钱还是账户信用。 平台要求先付款才不停服时，先想清楚这个账号下面挂着什么，再决定付不付，付了也要留好全部记录。 六、我把这套检查做成了一个 Skill 上面五件事落到每个人头上都不一样：有人只用 Cloudflare，有人是 Vercel + Supabase + Gemini + Stripe 全家桶。各家的刹车也在按月变化，OpenAI 7 月才加上硬上限，Cloudflare 的还没来。写成固定清单，三个月就过时了。 所以我做了一个 YouMind Skill，叫「云服务防背刺体检」。你用一句话告诉它在用哪些服务，它先去查这些平台当天的官方文档，再按上面这套逻辑出一份报告：最坏情况能烧多少、每个平台的红黄绿评级、今天 30 分钟内要点哪些开关，以及可以直接丢给 AI 修代码的提示词。贴代码的话，它会找自我调度的循环、无限重试、全表扫描、前端暴露的 Key 和没开 RLS 的表。如果你说的是「已经出事了」，它跳过体检，直接告诉你先停什么、截什么。 我用「Vercel 前端 + Supabase Pro + Cloudflare Durable Objects 跑定时任务 + Gemini 生图 + Stripe 收款，没设过上限」试了一次，报告的第一句是： 最危险的是 Cloudflare Durable Objects：账户没有任何到线会停的上限（预算提醒只发邮件，不算刹车），而 alarm 一旦在回调里给自己重新定时，零用户也会每秒跑几百次——shmily7 的测试项目就这样烧出了 $10,811.41 的账单。第二是 Gemini 生图：没设项目上限，Key 要是在前端，任何人都能拿去刷你的钱。 它不会替你登录后台，也不改你的代码，查不到的写「需要你确认」。不要给它贴完整的 Key 和密码，它会拒收，并提醒你去吊销重建。 Skill 地址：云服务防背刺体检 来源 Cloudflare 事故：Billflare 案例库 / Durable Objects 专题 / shmily7（X 原帖、每秒 600 次的复盘）/ Will Moss / dev.in1 / Steven Menke / zmuleyu / Jiuhong / babynarc / Lion Brain / Standard Agents / 队列循环约 $36,000 / 被要求 $120K Enterprise 其他账单：Netlify $104K / Vercel $23K 等 Key 与权限：Gemini $82K · The Register / Gemini $55,444 · Reddit / $10 提醒被刷 $1,300 · Reddit / Lovable RLS 漏洞 账号与资金：Hetzner 账户被删 / Stripe 冻结 $130K · Reddit / Card Testing 一天 $12K · Reddit 官方文档：Cloudflare 硬上限计划 / Vercel Spend Management / Supabase Cost Control / Gemini 费用控制更新 / Gemini Billing / Gemini 上限细节整理（第三方）

   These source blocks are preserved as an appendix without changing the article text.

   Appendix 1 · none

   | 平台 | 有没有会停服的上限 | 踩下去的代价 / 容易踩的坑 |
   | --- | --- | --- |
   | Cloudflare | **没有** | 官方 10 月 2 日说硬上限还在做原型，目标 Q4 小范围开放，截至今天没上线。默认开着的预算提醒只发邮件。现在能做的：调低单次调用的 CPU 上限（只管单次，不管总量）、给 AI Gateway 单独设花费上限、删掉不用的 Worker 和 Durable Objects |
   | Vercel | 有：Spend Management + 暂停生产部署 | 到线后网站、API、函数全部下线，要手动恢复。只设金额不开暂停，就只是提醒 |
   | Supabase | 部分有：Pro 的 Spend Cap | 超额后服务受限；Compute 这类固定费用不在保护范围内，多开项目会另外收费 |
   | OpenAI | 有：组织级、项目级硬上限 | 超了返回 429；不是即时生效，会多漏一点 |
   | Gemini（AI Studio） | 有：项目月度上限 + 账户级月度上限 | 项目上限是实验功能，可能多跑约 10 分钟的用量；账户级上限一到，同一结算账户下**所有项目一起停到下月 1 日** |
   | Stripe | 不适用 | 风险在资金冻结（有商户被冻约 $130,000）和盗卡测试（有人一天被收约 $12,000 费用） |

   Appendix 2 · none

   | 案例 | 金额（USD） | 结果 |
   | --- | --- | --- |
   | shmily7 | 10,811.41 | 先付清；客服先拒，员工在 X 上看到后介入，10-09 处理退款 $10,701.41（差 $110），作者称尚未到账 |
   | Standard Agents | 8,846 | 账单被调整 |
   | dev.in1 | 3,800+ | 客服按标准政策拒绝 |
   | Steven Menke | 1,700 | 工单几个月没人回 |
   | zmuleyu | 1,481.11 | 退 $976，给的是账户信用，剩下 $500 自己付 |
   | Jiuhong | 600+ | 多轮交涉后退 80%，也是账户信用 |
   | babynarc | 300 → 500 | 关掉服务后账单还在涨，没见减免 |

2. Undated

   The article’s YouMind Skill “云服务防背刺体检”: per the article, it checks the named platforms’ official docs on the day, rates the worst-case burn per platform, lists switches to turn on and gives code-fix prompts; it does not log in to dashboards or modify code.

   Open original source