Delay Step
The Delay step pauses flow execution for a specified duration before continuing to the next step. Use it for time-based workflows, retry logic with backoff, scheduled follow-ups, or giving external systems time to process.Delays are non-blocking: While a flow waits, your system resources remain available for other flows. Delays don’t consume compute time.
How It Works
Delay pauses the flow, waits for the specified time, then continues:When to Use Delay
| Use When | Don’t Use When |
|---|---|
| Time-based follow-ups (drip campaigns) | Immediate execution needed |
| Retry logic (wait before retry) | No time dependency |
| Give external systems time to process | Real-time response required |
| Rate limiting (space out API calls) | High-volume operations |
| Scheduled reminders | User-triggered events |
| Cool-down periods | Always-on monitoring |
Configuration
Duration
How long to waitStructure:Units:
seconds- For short delays (1-59 seconds)minutes- For medium delays (1-59 minutes)hours- For longer delays (1-23 hours)days- For multi-day delays (1-30 days)
Dynamic Duration
Calculate delay duration from previous step dataWhen enabled, duration can reference variables:Use when: Delay duration depends on data (e.g., customer tier, response time)
Until Time
Wait until specific date/time (instead of duration)Format: ISO 8601 datetimeExamples:Use when: Need to align with specific time (e.g., send at 9am)
Common Patterns
Drip Email Campaign
Drip Email Campaign
Space out email sends over timeUse when: Onboarding sequences, nurture campaigns
Follow-Up Reminder
Follow-Up Reminder
Send reminder if no responseUse when: Sales outreach, pending approvals, overdue items
Retry with Exponential Backoff
Retry with Exponential Backoff
Retry failed operations with increasing delaysUse when: External API calls, transient failures
Rate Limiting
Rate Limiting
Space out API calls to respect rate limitsUse when: Batch processing with API rate limits
Cool-Down Period
Cool-Down Period
Prevent repeated actions too quicklyUse when: Prevent spam, throttle notifications
Scheduled Send
Scheduled Send
Wait until specific time to sendUse when: Reports, scheduled communications
Time-Based Check-In
Time-Based Check-In
Check status after time periodUse when: Polling for job completion, async operations
Trial Expiration Reminder
Trial Expiration Reminder
Remind before subscription endsUse when: Subscription management, time-limited access
Real-World Examples
Example 1: Onboarding Email Sequence
Example 2: Payment Retry Logic
Example 3: Support Ticket Follow-Up
Best Practices
Use Appropriate Units
Seconds for retry logic, minutes for quick follow-ups, hours/days for campaigns. Choose the unit that best matches your use case.
Consider Time Zones
For scheduled sends, account for customer time zones. Use “Until Time” with localized times.
Set Maximum Retry Attempts
Don’t retry forever. Set a maximum number of attempts before giving up or escalating.
Monitor Delayed Flows
Track how many flows are waiting. Long delays create many pending executions.
Test with Short Delays
During development, use seconds instead of hours/days to test faster.
Document Delay Reasons
Add descriptions explaining why each delay exists and why that duration was chosen.
Troubleshooting
Flow never continues after delay
Flow never continues after delay
Causes:
- Delay duration too long
- Flow execution failed
- System issue
- Check flow execution logs
- Verify delay configuration
- Check for errors after delay
- Contact support if system issue
Delay not respecting duration
Delay not respecting duration
Causes:
- Wrong unit specified
- Dynamic duration calculation error
- Variable reference incorrect
- Verify unit (seconds/minutes/hours/days)
- Check dynamic duration calculation
- Verify variable paths if using dynamic
- Test with static duration first
Too many flows waiting
Too many flows waiting
Causes:
- Long delays create backlog
- High trigger volume
- Delays not necessary
- Review if all delays are needed
- Shorten delay durations if possible
- Consider alternative approaches (webhooks instead of polling)
- Monitor pending flow count
Scheduled send at wrong time
Scheduled send at wrong time
Causes:
- Time zone mismatch
- Incorrect “Until Time” format
- Clock drift
- Use ISO 8601 format with timezone
- Account for user’s timezone
- Test scheduled sends with near-future times
- Verify time zone settings
Performance Considerations
Delays don't consume resources
Delays don't consume resources
Delayed flows don’t use compute time while waiting. They’re paused and resumed automatically.Cost: Minimal storage for flow state, no compute cost during delay
Maximum delay duration
Maximum delay duration
Limits:
- Maximum: 30 days per delay step
- For longer delays: Chain multiple delay steps
- For scheduled sends: Use “Until Time” for any future date
Scale considerations
Scale considerations
High-volume triggers with delays can create many pending flows:
- 1,000 signups/day with 7-day sequence = 7,000 pending flows
- Monitor pending flow count
- Delays are efficient, but plan for scale
Delay vs. Schedule Trigger
Use Delay when: Within a flow, need to pause between steps Use Schedule Trigger when: Starting a new flow at specific time/interval| Delay Step | Schedule Trigger |
|---|---|
| Pauses existing flow | Starts new flow |
| Relative time (from now) | Absolute time (specific schedule) |
| Part of workflow sequence | Independent execution |
| One-time pause | Recurring schedule |
✅ Use Schedule: Send newsletter every Monday at 9am