Skip to main content

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:
Agent: Send welcome email

Delay: 24 hours

Agent: Send follow-up email

When to Use Delay

Use WhenDon’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 processReal-time response required
Rate limiting (space out API calls)High-volume operations
Scheduled remindersUser-triggered events
Cool-down periodsAlways-on monitoring

Configuration

Duration

duration
object
required
How long to waitStructure:
{
  "value": 5,
  "unit": "minutes"
}
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)
Examples:
// Wait 30 seconds
{"value": 30, "unit": "seconds"}

// Wait 5 minutes
{"value": 5, "unit": "minutes"}

// Wait 24 hours
{"value": 24, "unit": "hours"}

// Wait 7 days
{"value": 7, "unit": "days"}

Dynamic Duration

dynamicDuration
boolean
default:"false"
Calculate delay duration from previous step dataWhen enabled, duration can reference variables:
{
  "value": "${calculated_delay}",
  "unit": "minutes"
}
Use when: Delay duration depends on data (e.g., customer tier, response time)

Until Time

untilTime
string
Wait until specific date/time (instead of duration)Format: ISO 8601 datetimeExamples:
// Wait until specific date and time
"2025-10-17T09:00:00Z"

// Can use variables
"${scheduled_send_time}"
Use when: Need to align with specific time (e.g., send at 9am)

Common Patterns

Space out email sends over time
Trigger: User signs up

Agent: Send welcome email (Day 0)

Delay: 2 days

Agent: Send getting started email (Day 2)

Delay: 3 days

Agent: Send tips and tricks email (Day 5)

Delay: 5 days

Agent: Send upgrade prompt email (Day 10)
Use when: Onboarding sequences, nurture campaigns
Send reminder if no response
Agent: Send proposal email

Delay: 3 days

Condition: Response received?
├─ Yes → End flow
└─ No → Agent: Send follow-up

    Delay: 7 days

    Condition: Response received?
    ├─ Yes → End flow
    └─ No → Agent: Final follow-up
Use when: Sales outreach, pending approvals, overdue items
Retry failed operations with increasing delays
HTTP Request: Call API

Condition: Success?
├─ Yes → Continue
└─ No → Delay: 1 second

    HTTP Request: Retry 1

    Condition: Success?
    ├─ Yes → Continue
    └─ No → Delay: 2 seconds

        HTTP Request: Retry 2

        Condition: Success?
        ├─ Yes → Continue
        └─ No → Delay: 4 seconds

            HTTP Request: Final retry
Use when: External API calls, transient failures
Space out API calls to respect rate limits
Map: Process each item in array

For each item:
  HTTP Request: Call API

  Delay: 1 second

  Next item
Use when: Batch processing with API rate limits
Prevent repeated actions too quickly
Agent: Sends notification

Delay: 1 hour

(User can't trigger same notification again during delay)
Use when: Prevent spam, throttle notifications
Wait until specific time to send
Agent: Generate report

Delay: Until 9:00 AM next business day

Agent: Send report email
Use when: Reports, scheduled communications
Check status after time period
HTTP Request: Start long-running job

Delay: 30 seconds

HTTP Request: Check job status

Condition: Complete?
├─ Yes → Continue
└─ No → Delay: 30 seconds

    HTTP Request: Check again

    (Repeat until complete or max attempts)
Use when: Polling for job completion, async operations
Remind before subscription ends
Trigger: Trial started

Delay: 11 days (for 14-day trial)

Agent: Send "3 days left" reminder

Delay: 2 days

Agent: Send "1 day left" reminder

Delay: 1 day

Condition: Upgraded?
├─ Yes → End flow
└─ No → Agent: Trial expired notification
Use when: Subscription management, time-limited access

Real-World Examples

Example 1: Onboarding Email Sequence

Trigger: New user signup
  Data: {email, name, signup_date}

Agent: Send welcome email
  To: ${trigger.email}
  Content: Welcome message, getting started guide

Delay: 1 day

Agent: Send feature overview email
  To: ${trigger.email}
  Content: Key features, video tutorials

Delay: 3 days

HTTP Request: Check user activity
  URL: /api/users/${trigger.user_id}/activity

Condition: User active?
├─ Yes → Agent: Send power user tips
│   ↓
│   Delay: 5 days
│   ↓
│   Agent: Send upgrade prompt
└─ No → Agent: Send re-engagement email

    Delay: 2 days

    Condition: Still inactive?
    └─ Yes → Agent: Final re-engagement attempt

Example 2: Payment Retry Logic

Trigger: Payment failed
  Data: {customer_id, amount, payment_method}

Agent: Analyze failure reason
  Output: {retryable: true, recommended_delay: 24}

Condition: Retryable?
├─ No → Agent: Notify customer (non-retryable)
└─ Yes → Delay: 24 hours

    HTTP Request: Retry payment

    Condition: Success?
    ├─ Yes → Agent: Send success confirmation
    └─ No → Delay: 48 hours

        HTTP Request: Second retry

        Condition: Success?
        ├─ Yes → Agent: Send success confirmation
        └─ No → Agent: Request payment method update

Example 3: Support Ticket Follow-Up

Trigger: Support ticket resolved
  Data: {ticket_id, customer_email, resolution}

Agent: Send resolution confirmation
  To: ${trigger.customer_email}
  Content: Summary of resolution

Delay: 3 days

HTTP Request: Check if ticket reopened
  URL: /api/tickets/${trigger.ticket_id}

Condition: Still closed?
├─ No → End flow (customer responded)
└─ Yes → Agent: Send satisfaction survey
    To: ${trigger.customer_email}
    Content: "How was your experience?"

    Delay: 7 days

    HTTP Request: Check for survey response

    Condition: Survey completed?
    ├─ Yes → End flow
    └─ No → Agent: Survey reminder

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

Causes:
  • Delay duration too long
  • Flow execution failed
  • System issue
Solutions:
  • Check flow execution logs
  • Verify delay configuration
  • Check for errors after delay
  • Contact support if system issue
Causes:
  • Wrong unit specified
  • Dynamic duration calculation error
  • Variable reference incorrect
Solutions:
  • Verify unit (seconds/minutes/hours/days)
  • Check dynamic duration calculation
  • Verify variable paths if using dynamic
  • Test with static duration first
Causes:
  • Long delays create backlog
  • High trigger volume
  • Delays not necessary
Solutions:
  • Review if all delays are needed
  • Shorten delay durations if possible
  • Consider alternative approaches (webhooks instead of polling)
  • Monitor pending flow count
Causes:
  • Time zone mismatch
  • Incorrect “Until Time” format
  • Clock drift
Solutions:
  • Use ISO 8601 format with timezone
  • Account for user’s timezone
  • Test scheduled sends with near-future times
  • Verify time zone settings

Performance Considerations

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
Limits:
  • Maximum: 30 days per delay step
  • For longer delays: Chain multiple delay steps
  • For scheduled sends: Use “Until Time” for any future date
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 StepSchedule Trigger
Pauses existing flowStarts new flow
Relative time (from now)Absolute time (specific schedule)
Part of workflow sequenceIndependent execution
One-time pauseRecurring schedule
Example: Use Delay: User signs up → Wait 3 days → Send email
Use Schedule: Send newsletter every Monday at 9am

Next Steps