Pause Node
The Sleep node pauses your workflow for a set amount of time. It’s like pressing pause on a video - everything stops, then continues after the time is up.
When to Use
- Avoiding overload - Wait between requests so you don’t get blocked
- Trying again later - Wait a bit before retrying something that failed
- Scheduling - Pause until a specific time
- Checking status - Wait between checks to see if something is done
- Spacing out messages - Don’t send everything at once
Example: Rate-Limited API Calls
Respect API rate limits when making multiple calls:
├── Loop (over items)
│ ├── HTTP Request (call API)
│ ├── Condition ({{loop_1.isLast}})
│ │ └── Unmet: Sleep (1 second)
This adds a 1-second delay between API calls, avoiding rate limits.
Example: Retry with Backoff
Retry a failed operation after waiting:
Make the initial request
Use an HTTP Request node to call the API.
Check for errors
Add a Condition to check if it failed.
Retry with delay
On failure:├── Condition (success?)
│ ├── Met: Continue
│ └── Unmet:
│ ├── Set Variable (retryCount += 1)
│ ├── Condition (retryCount < 3)
│ │ ├── Met:
│ │ │ └── Sleep ({{retryCount * 5}} seconds)
│ │ │ → [Loop back to HTTP Request]
│ │ └── Unmet: Alert (max retries exceeded)
Example: Scheduled Follow-Up
Send a follow-up email after a delay:
├── External API (send initial email)
├── Sleep (2 days)
├── Condition (customer replied?)
│ ├── Met: (don't send follow-up)
│ └── Unmet: External API (send follow-up email)
Example: Polling for Completion
Wait for an async operation to complete:
├── HTTP Request (start long-running job, get jobId)
├── Set Variable (status = "pending")
├── Loop (while status != "completed")
│ ├── Sleep (30 seconds)
│ ├── HTTP Request (check job status)
│ ├── Set Variable (status = response.status)
│ ├── Condition (status == "completed" OR status == "failed")
│ │ └── Met: [exit loop]
Duration Examples
| Configuration | Total Wait |
|---|
| 30 seconds | 30 seconds |
| 5 minutes | 5 minutes |
| 2 hours | 2 hours |
| 1 day | 24 hours |
Using resumeAt
Instead of a duration, specify an exact time:
{
"resumeAt": "2024-03-15T09:00:00Z"
}
The workflow resumes at exactly that time.
Dynamic resume time:
resumeAt: {{execute_code_1.result.scheduledTime}}
Where Execute Code calculates when to resume:
from datetime import datetime, timedelta
# Resume tomorrow at 9 AM
tomorrow = datetime.now() + timedelta(days=1)
resume_time = tomorrow.replace(hour=9, minute=0, second=0)
return {"scheduledTime": resume_time.isoformat()}
Sleep vs. Recurrent Event
| Feature | Sleep | Recurrent Event |
|---|
| When to use | Delay within a workflow | Schedule workflow start |
| Duration | Single delay | Repeating schedule |
| Context | Has access to previous node data | Starts fresh |
| Use case | ”Wait 5 min, then continue" | "Run every morning at 9” |
Use Pause for delays mid-workflow. Use Scheduled Trigger to schedule when workflows start.
Maximum Sleep Duration
Very long sleep durations (days/weeks) keep the workflow execution in memory. For long delays, consider:
- Ending the workflow and using a Recurrent Event
- Storing state in a variable and using On Variable Changed
- Using an external scheduler to trigger a webhook
Practical limits:
- Up to 1 hour - Works well
- Up to 24 hours - Generally reliable
- Longer - Consider alternative approaches
Tips
For rate limiting in loops, check isLast before sleeping to avoid an unnecessary delay after the final item.
Use exponential backoff for retries: Sleep for 2^retryCount seconds (2, 4, 8, 16…) to give failing services more recovery time.
When polling, start with shorter intervals and increase them over time to balance responsiveness with API efficiency.
Settings
What to call this node (shown on the canvas).
A short code to reference this node’s info.
The time unit: seconds, minutes, hours, or days.
Instead of a duration, you can specify an exact time to wake up.
Outputs
How long it actually waited (in milliseconds).
When it woke up and continued.