Durable Objects alarms
Cloudflare documents how Durable Object alarms are scheduled, retried, and deleted.
- Products
- Durable Objects
- Source
- Official docsCloudflare Docs
Key points
- Each Durable Object can have one alarm at a time; calling setAlarm while one is scheduled overrides it. Alarms let work run without incoming requests keeping the object alive, and the alarm() handler can set future alarms.
- alarm() has at-least-once execution. When it throws an uncaught exception, it is retried with exponential backoff starting at 2 seconds, up to 6 retries; this applies only to the most recent setAlarm() call.
- If the constructor calls setAlarm, the docs say to check first whether an alarm is already set, because the constructor runs before alarm() when an inactive object wakes. Calling deleteAlarm() inside alarm() may prevent retries only on a best-effort basis.
Original sources
Undated
Original post
Open original sourceUndated
Durable Objects pricing: alarm invocations count toward billed requests. With SQLite-backed storage, each setAlarm() is billed as one row written; with key-value storage, as one write request unit.
Open original source
More to read
Author experienceWorkers +5
Four layers of cost protection for small Cloudflare projects
David Z (@davezfr) writes an X article for vibe coders on budget alerts, stop conditions for paid paths, automatic pausing, and letting a personal agent verify and pause.
Durable Objects
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.
Official docsAccount-wide usage-based products
Budget alerts
Cloudflare documents account-wide spend alerts and their notification limits.