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

HTTP Request: Call external API
↓
Condition: Failed?
├─ Yes → Delay: 5 seconds
│   ↓
│   HTTP Request: Retry
│   ↓
│   Condition: Failed again?
│   ├─ Yes → Delay: 10 seconds
│   │   ↓
│   │   HTTP Request: Final retry
│   └─ No → Continue
└─ No → Continue

Agent: Send email 1
↓
Delay: 3 days
↓
Agent: Send email 2
↓
Delay: 3 days
↓
Agent: Send email 3

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

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

Drip Email Campaign

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

Follow-Up Reminder

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 with Exponential Backoff

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

Rate Limiting

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

Cool-Down Period

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

Scheduled Send

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

Time-Based Check-In

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

Trial Expiration Reminder

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

Flow never continues after delay

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

Delay not respecting duration

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

Too many flows waiting

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

Scheduled send at wrong time

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

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

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

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

Example: ✅ Use Delay: User signs up → Wait 3 days → Send email
✅ Use Schedule: Send newsletter every Monday at 9am

Next Steps

Condition Step

Check conditions after delays

Schedule Trigger

Start flows on a schedule

HTTP Request

Retry API calls with delays

Agents

Send time-delayed communications

Get Started

Assistants

Flows

Account Management

Advanced

Delay

Delay Step

How It Works

When to Use Delay

Configuration

Duration

Dynamic Duration

Until Time

Common Patterns

Real-World Examples

Example 1: Onboarding Email Sequence

Example 2: Payment Retry Logic

Example 3: Support Ticket Follow-Up

Best Practices

Use Appropriate Units

Consider Time Zones

Set Maximum Retry Attempts

Monitor Delayed Flows

Test with Short Delays

Document Delay Reasons

Troubleshooting

Performance Considerations

Delay vs. Schedule Trigger

Next Steps

Condition Step

Schedule Trigger

HTTP Request

Agents

​Delay Step

​How It Works

​When to Use Delay

​Configuration

​Duration

​Dynamic Duration

​Until Time

​Common Patterns

​Real-World Examples

​Example 1: Onboarding Email Sequence

​Example 2: Payment Retry Logic

​Example 3: Support Ticket Follow-Up

​Best Practices

Use Appropriate Units

Consider Time Zones

Set Maximum Retry Attempts

Monitor Delayed Flows

Test with Short Delays

Document Delay Reasons

​Troubleshooting

​Performance Considerations

​Delay vs. Schedule Trigger

​Next Steps

Condition Step

Schedule Trigger

HTTP Request

Agents

Delay Step

How It Works

When to Use Delay

Configuration

Duration

Dynamic Duration

Until Time

Common Patterns

Real-World Examples

Example 1: Onboarding Email Sequence

Example 2: Payment Retry Logic

Example 3: Support Ticket Follow-Up

Best Practices

Troubleshooting

Performance Considerations

Delay vs. Schedule Trigger

Next Steps