Sleep, Scheduling & Timed Workflows
Workflow's sleep() is durable: it survives cold starts, restarts, and deployments. Combined with defineHook() and Promise.race(), it becomes the foundation for interruptible scheduled workflows like drip campaigns, reminders, and timed sequences.
Scheduled workflows are still pinned to the deployment that started them. If you are building recurring or indefinitely running schedules that should adopt newer code over time, see Versioning for the explicit deploymentId: "latest" continuation pattern.
When to use this
- Sending emails on a schedule, such as drip campaigns, onboarding sequences, or reminders
- Waiting for a deadline while allowing early cancellation
- Reliable, interruptible patterns that perform one action, wait for a specified time, and then perform another action
Drip campaign with cancellation
A drip campaign sends emails at intervals, sleeping between each message. Each sleep races against a cancellation hook. If an external event fires the hook, such as when a user converts or unsubscribes, the campaign stops immediately.
Cancelling from an API route
Any server-side code can fire the hook by calling .resume() with the same token:
How it works
- Durable sleep:
sleep("2d")persists through restarts at zero compute cost. The workflow resumes when the timer fires. - Hook creation:
cancelDrip.create({ token })registers a hook that resolves when any external system calls.resume()with the same token. - Race:
Promise.race([sleep(...), hook])blocks until either the timer fires or the hook is resumed, whichever comes first. - Fresh hooks per window: After a sleep completes normally, the previous hook instance is consumed. A new
.create()call registers a fresh hook for the next sleep window, reusing the same token.
Deterministic hook tokens can also serve as the idempotency point for scheduled runs. If duplicate schedule starts would send duplicate campaigns or reminders, create a hook with a token derived from the campaign key near the beginning of the workflow and route retries through that hook. If two scheduled starts race, the duplicate run can detect the conflict early with await hook.getConflict(), which resolves with the active owner so the duplicate can defer to it. See Idempotency.
Adapting to your use case
- Change durations: Replace
"2d"with any duration string ("1h","7d", or"30m") or aDateobject for absolute times. - Add more steps: The pattern scales to any number of email-then-sleep pairs.
- Snooze instead of cancel: Resolve the hook with a
snoozepayload and sleep again withsleep(new Date(Date.now() + payload.snoozeMs)). - Set a timeout for any operation: Use the same
Promise.race(sleep, work)pattern to add deadlines to slow steps. - Use production providers: Replace the
sendEmailstep body with Resend, Postmark, or any HTTP API. The"use step"function has full Node.js access.
Tips
- Pass supported values to
sleep(): Use duration strings ("1d","2h", or"30s"), milliseconds, orDateobjects for sleeping until a specific time. - Sleeping consumes no compute or memory: A workflow waiting on
sleep("7d")consumes no compute or memory while sleeping. - Use
sleep()only in workflow context: Step functions cannot callsleep()directly. If a step needs a delay, usesetTimeoutinside the step.
Key APIs
"use workflow": Marks the orchestrator function."use step": Marks functions that run with full Node.js access.sleep(): Provides a durable wait that survives restarts with zero compute cost.defineHook(): Creates a typed hook that external systems can fire.Promise.race(): Races sleep against hooks for interruptible waits.