Skip to main content

​
Time Delay

The Time Delay step pauses workflow execution for a specified duration. This allows you to create workflows that wait before executing subsequent steps.

​
Overview

Time Delay steps are essential for:
  • Creating follow-up email sequences
  • Implementing retry logic with delays
  • Spacing out API calls
  • Building time-based automation

​
Configuration

When you add a Time Delay step to your workflow, you’ll need to configure:

​
Duration

The amount of time to wait before continuing execution.
  • Value: Enter a numeric value (e.g., 5, 30, 120)
  • Unit: Select from the available time units

​
Time Units

Choose from the following time units:
  • Seconds: For short delays (1-59 seconds)
  • Minutes: For medium delays (1-59 minutes)
  • Hours: For longer delays (1-23 hours)
  • Days: For extended delays (1+ days)
The minimum delay duration is 1 second. There is no maximum limit, but very long delays (days or weeks) should be used with schedule triggers instead.

​
Example Use Cases

​
Follow-up Email Sequence

Create a sequence that sends a follow-up email 3 days after the initial email: 
Trigger (Event: User Signs Up)
  ↓
Send Email (Welcome Email)
  ↓
Time Delay (3 days)
  ↓
Send Email (Follow-up Email)

​
Retry Logic with Exponential Backoff

Implement retry logic that waits progressively longer between attempts: 
HTTP Request (API Call)
  ↓
True/False Branch (Check if failed)
  ├─ True → Time Delay (30 seconds) → HTTP Request (Retry)
  └─ False → Continue

​
Rate-Limited API Calls

Space out API calls to respect rate limits: 
HTTP Request (Call 1)
  ↓
Time Delay (1 minute)
  ↓
HTTP Request (Call 2)
  ↓
Time Delay (1 minute)
  ↓
HTTP Request (Call 3)

​
Best Practices

Use the smallest unit that makes sense for your delay. For example, use seconds for delays under a minute, and minutes for delays under an hour.
Very long delays (days or weeks) are better handled with schedule triggers rather than delay steps, as they’re more reliable and don’t consume workflow execution resources.
When testing workflows with delays, use shorter durations (seconds) to verify behavior before deploying with longer delays.
You can use workflow variables in delay configurations if you need dynamic delays based on data from previous steps or trigger events.
Delays are executed server-side and count toward your workflow execution time. Very long delays may impact workflow performance and costs.