> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flowripple.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Time Delay

> Configure time-based delays in your workflows to pause execution for a specified duration.

# 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)

<Note>
  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.
</Note>

## 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

<AccordionGroup>
  <Accordion title="Choose Appropriate Units">
    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.
  </Accordion>

  <Accordion title="Consider Workflow Context">
    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.
  </Accordion>

  <Accordion title="Test Delay Behavior">
    When testing workflows with delays, use shorter durations (seconds) to verify behavior before deploying with longer delays.
  </Accordion>
</AccordionGroup>

<Tip>
  You can use workflow variables in delay configurations if you need dynamic delays based on data from previous steps or trigger events.
</Tip>

<Warning>
  Delays are executed server-side and count toward your workflow execution time. Very long delays may impact workflow performance and costs.
</Warning>