Delay delay

When to Use

• Rate limiting between API calls: Insert a 1-second delay inside a Loop body to space out external API calls and avoid hitting per-second rate limits — for example, sending 500 SMS messages one per second rather than in a burst.
• Scheduled follow-up communication: After sending a welcome email, pause for 3 days then send an onboarding follow-up. Use delay_type: "duration" with duration_ms: 259200000 (72 hours) or drive the value from a workflow variable.
• SLA enforcement and escalation: After a support ticket is created, delay 2 hours. If not resolved when the workflow resumes, trigger an escalation notification to a supervisor automatically.
• Timed content or feature release: Hold a workflow at the Delay node until a specific UTC datetime — the product launch window — then proceed to publish content, flip a feature flag, or send a coordinated announcement.
• Retry back-off: After a failed payment attempt, delay 5 minutes before retrying the charge. Use an expression to compute exponential back-off durations across multiple retry iterations.

Configuration

Sample Configuration

Fixed 5-minute duration delay

{
  "delay_type": "duration",
  "duration_minutes": 5
}

Dynamic duration from a workflow variable (retry back-off)

{
  "delay_type": "duration",
  "duration_expression": "{{ $var.retry_delay_ms }}"
}

Until a specific UTC datetime (launch window)

{
  "delay_type": "until",
  "until_utc": "2026-09-01T08:00:00Z"
}

Until a datetime from trigger data (contract start date)

{
  "delay_type": "until",
  "until_expression": "{{ $json.contractStartDate }}"
}

Short in-process delay with custom threshold

{
  "delay_type": "duration",
  "duration_ms": 1000,
  "in_process_threshold_ms": 5000
}

Validation Errors

Output / Execution Ports

success and cancelled Ports — Output Fields

waiting Port — Output Fields

Sample Output

success port (durable delay completed)

{
  "delay": {
    "requested_ms": 259200000,
    "actual_ms": 259200341,
    "resumed_at": "2026-05-29T09:00:00Z",
    "mode": "durable"
  }
}

waiting port (durable delay initiated)

{
  "delay": {
    "id": 8821,
    "requested_ms": 259200000,
    "resume_after": "2026-05-29T09:00:00Z",
    "mode": "durable"
  }
}

success port (until mode, target was in the past — skipped)

{
  "delay": {
    "requested_ms": 0,
    "actual_ms": 0,
    "resumed_at": "2026-05-26T14:22:11Z",
    "mode": "skipped"
  }
}

Expression Reference

Node Policies & GuardRails

Examples

Example 1 — 3-Day Follow-Up Email After Onboarding

After a new user registers and receives a welcome email, the workflow pauses for 3 days using a durable delay, then sends a follow-up email checking on their progress. The durable delay survives any server restarts during the 3-day window.

WebhookTrigger  [key: "userRegistered"]
  (POST /users/register)
  └─► EmailSmtp  [key: "sendWelcome"]
        To: {{ $json.email }}
        Subject: "Welcome to BizFirstAI"
        └─► Delay  [key: "waitThreeDays"]
              delay_type: "duration"
              duration_ms: 259200000     // 3 days in ms
              ├─► waiting ──► Slack  (log: "Follow-up pending for {{ $json.email }}, delay.id: {{ $output.waitThreeDays.delay.id }}")
              └─► success ──► EmailSmtp  [key: "sendFollowUp"]
                              To: {{ $json.email }}
                              Subject: "How are you getting on?"

Example 2 — Rate-Limited API Calls in a Loop

A batch job processes 500 customer records and must call an external enrichment API for each. The API enforces a 1 request-per-second limit. A 1-second in-process delay between calls ensures compliance.

MongoDB  [key: "getCustomers"]
  (find all customers needing enrichment)
  └─► Loop  [key: "enrichLoop"]
        Items: {{ $output.getCustomers.documents }}
        ├─► body ──► HttpRequest  [key: "enrichCustomer"]
        │             GET /enrich/{{ $var.current_item.customerId }}
        │             └─► Delay  [key: "rateLimitPause"]
        │                   delay_type: "duration"
        │                   duration_ms: 1000        // 1 second — in-process (below 30s threshold)
        │                   └─► success ──► MongoDB  (update customer with enriched fields)
        └─► done ──► Slack  (batch complete: {{ $output.enrichLoop.collection_size }} customers enriched)

Example 3 — SLA Escalation After 2-Hour Wait

After a support ticket is created, the workflow waits 2 hours using a durable delay. When it resumes, it checks the ticket status. If still open, an escalation notification is sent to the supervisor. The delay ID is logged immediately so the ops team can monitor pending escalations.

WebhookTrigger  [key: "ticketCreated"]
  (POST /support/tickets)
  └─► Delay  [key: "slaWindow"]
        delay_type: "duration"
        duration_minutes: 120               // 2-hour SLA window
        ├─► waiting ──► HttpRequest  (POST /ops/pending-slas  body: { delayId: {{ $output.slaWindow.delay.id }}, ticketId: {{ $json.ticketId }} })
        └─► success ──► HttpRequest  [key: "checkTicketStatus"]
                          GET /support/tickets/{{ $json.ticketId }}
                          └─► IfCondition
                                Condition: {{ $output.checkTicketStatus.status == "open" }}
                                ├─► true  ──► EmailSmtp  (To: supervisor — escalation: ticket {{ $json.ticketId }} unresolved after 2h)
                                └─► false ──► StopWorkflow  (status: success, message: "Ticket resolved within SLA")