Five durable workflows you can click

Each of these normally takes days or weeks. Every one of them is a pure state machine over a persisted row, so the waits are just timestamps — which means the ⏩ buttons can fast-forward them, and the 💥 buttons can destroy the server without losing the work.

Durable agent run

—

An AI agent working a support ticket over several model calls, with a spend cap and a human approval in the middle.

The approval wait has no timer at all. Nothing is scheduled — the run simply stops until a human says yes, which may be days and several deploys later. A process holding a promise cannot wait that long. A row can.


      
In production these ⏩ buttons are Durable Object alarms — nobody clicks anything.

    

    

      

        
Dunning

        —
      

      
A subscription whose card was declined: billing retries on day 1, day 3 and day 7, then a 14-day grace period, then a downgrade.

      
A 21-day process cannot live in a process. There is no runtime you can hold open for three weeks, so the schedule is not a schedule — it is arithmetic on a number in a row.

      

      

      

      
      

      

      
In production these ⏩ buttons are Durable Object alarms — nobody clicks anything.

    

    

      

        
Approval chain

        —
      

      
An expense report walking three approvers in order, each chased with a reminder after two days and an escalation after seven.

      
State IS the audit log. Who approved what, when, and what we chased them with all live in the same row the machine runs on — so there is no separate events table for a failed write to desynchronise.

      

      

      

      
      

      

      
In production these ⏩ buttons are Durable Object alarms — nobody clicks anything.

    

    

      

        
Onboarding drip

        —
      

      
A new signup gets a welcome on day 1, a tip on day 3 and a check-in on day 7 — and the moment they actually use the product, the rest are cancelled.

      
Cancelling is deleting a number, not revoking a job. There is no queue to scan and no scheduler entry to chase: the due time becomes null and the drip is over.

      

      

      

      
      

      

      
In production these ⏩ buttons are Durable Object alarms — nobody clicks anything.

    

    

      

        
Fleet reconcile

        —
      

      
One device with a desired config and a reported config: push when they differ, back off when the push fails, stop when the device confirms.

      
Reconcile is a loop, and a loop that survives has to be re-entrant from state alone. Nothing remembers 'I was halfway through a push' — the revision numbers and the attempt count say it all, so any wake-up can recompute what is owed.

      

      

      

      
      

      

      
In production these ⏩ buttons are Durable Object alarms — nobody clicks anything.