Delay

Pause workflow execution for a specified duration or until a defined time, then resume with the original context fully preserved.

Workflow Node Execution Control Two Delay Modes 31-Day Max

What is the Delay node?

The Delay node is a workflow control node that pauses execution for a specified duration or until a defined time. When the delay completes, execution resumes with the original workflow payload intact — no data is lost during the pause.

It supports two types: Delay For (relative duration) and Delay Until (specific timestamp). Both types accept dynamic values mapped from upstream nodes.

What the Delay node lets you do

Pause a workflow for minutes, hours, days, or weeks
Wait until a specific date and time
Resume with the original payload fully intact
Build time-sensitive automations, follow-ups, reminders, and SLA enforcement

Prerequisites

What you'll need before adding a Delay node

An existing workflow in Konnectify with at least one upstream trigger or node.
For Delay For: a known duration value (fixed or mapped from an upstream field).
For Delay Until: a date/time value (fixed or mapped) that is within 31 days of execution.
Your user profile timezone configured correctly — Delay Until resolution uses profile-level timezone.

Understanding Delay Modes & Logic

The Delay node operates in one of two modes. Both use Slate text fields, meaning values can be entered manually or mapped dynamically from upstream nodes.

Delay modes

Mode	What it does	Example
Delay For	Pauses for a relative duration from the moment the node executes	Wait 30 minutes
Delay Until	Pauses until a specific absolute date and time is reached	Wait until 2025-06-01 09:00

Supported units (Delay For)

Unit	Minimum	Maximum
Minutes	1	44,640
Hours	1	744
Days	1	31
Weeks	1	4 (within 31-day cap)

Past date handling (Delay Until)

Option	Behavior
Continue if up to 15 minutes in the past	Resumes immediately if target was within the last 15 minutes
Continue if up to 1 hour in the past	Resumes immediately if target was within the last 1 hour
Continue if up to 1 day in the past DEFAULT	Resumes immediately if target was within the last 24 hours
Always continue	Resumes immediately regardless of how far in the past the target is
Fail	Step is marked as FAILED if the target date is in the past at all

Important: The system does not wait for past dates. If the target is outside the configured tolerance, the step fails immediately.

Key Components

Delay For RELATIVE DURATION

Pauses execution for a duration calculated from the moment the node runs. Requires two fields:

time_amount — the numeric duration value. Accepts manual input or dynamic mapping from upstream nodes. The backend converts this to a number — if conversion fails, the step is marked failed.
time_unit — the unit of time: MINUTES, HOURS, DAYS, or WEEKS.

Delay Until ABSOLUTE TIMESTAMP

Pauses execution until a specific date and time is reached. Requires one field:

target — a date/time value. Accepts manual input or a dynamic reference from an upstream field (e.g. {{ input.event_date }}). The backend converts this to a valid datetime — if conversion fails, the step is marked failed.

Past Date Handling (if_past) OPTIONAL

Applies to Delay Until mode only. Controls what happens when the target date is already in the past at execution time. Supports both dropdown selection (predefined options) and custom value mapping. The backend interprets the value as a valid datetime or a minutes-based tolerance — if neither works, the step is marked failed.

Timezone PROFILE-LEVEL

Timezone is not configured at the node level. Delay execution is based on backend execution time and the user profile-level timezone. All internal storage and queueing uses UTC.

When to Use

Use the Delay node when you need to introduce a time gap between steps — whether for a fixed wait or a dynamic timestamp from your data.

✓ Good fits

Sending a follow-up email 3 days after sign-up
Waiting until a scheduled meeting date before notifying
SLA enforcement — escalating if not resolved within 4 hours
Drip campaign pacing between messages
Reminder workflows tied to dynamic event dates

✗ Not the right tool

Triggering workflows on a recurring schedule (use a cron trigger)
Delays longer than 31 days (hard cap enforced at runtime)
Sub-second precision timing requirements
Chaining Delay nodes to exceed the 31-day limit

Step-by-step Guide

Add a Delay node

Open your workflow on the canvas.
Click the + button on any existing node.
Select Delay from the node type menu.
The sidebar opens automatically.

Choose a delay mode

Select Delay For to wait a relative duration, or Delay Until to wait until a specific date and time. The visible fields change based on your selection.

Configure the duration or target

Delay For: Enter a numeric value in duration and select a unit from time_unit. You can type a value manually or map it from an upstream node.
Delay Until: Enter or map a date/time value in the target field (e.g. {{ input.event_date }}). The value must be within 31 days of execution time in real runs.

Note: If the value cannot be converted to the expected type at runtime, the step is immediately marked as FAILED.

Set past date handling (Delay Until only)

Select how to handle cases where the target timestamp is already in the past.
The default is Continue if up to 1 day in the past.
For strict workflows, set to Fail to surface data issues early.

Save and connect downstream nodes

Click Continue to save the configuration.
Add the next node — it will execute once the delay completes and execution resumes.
Downstream nodes can reference _meta.delay fields from the injected metadata if needed.

Things to Know

Scenario	Behavior
time_amount is non-numeric	Step is immediately marked as FAILED
target is not a valid datetime	Step is immediately marked as FAILED
Delay Until target exceeds 31 days	Workflow fails immediately at runtime; not enforced during test runs
Target is past and within tolerance	Execution continues immediately — no waiting
Target is past and outside tolerance	Step fails — system does not wait for past dates
Duplicate execution triggered	Deduplicated by `execution_id + node_id`; ignored if already WAITING
Chaining Delay nodes to exceed 31 days	Not supported — may cause runtime errors

Node states

State	Description
SCHEDULED	Resume target has been calculated and persisted
WAITING	Job has been dispatched to the scheduler queue; execution is suspended
RESUMED	Delay completed; execution has restarted with original context
CANCELLED	Workflow was stopped while delay was in progress
FAILED	Configuration error, type conversion failure, or 31-day limit exceeded

Examples

Send a follow-up email 3 days after sign-up

Onboarding · Delay For · Fixed duration

DELAY FOR

A new user signs up. You want to wait 3 days before sending a check-in email.

Configuration

delay_typeFOR

time_amount3

time_unitDAYS

✓ Result — Execution pauses for exactly 3 days, then the email node fires with the original sign-up payload intact.

Notify attendees at the time of a scheduled event

Event management · Delay Until · Dynamic date mapping

DELAY UNTIL

An event record contains a start_time field. You want to send notifications precisely when the event begins, and fail the step if the date is already past.

Configuration

delay_typeUNTIL

target{{ input.start_time }}

if_pastFAIL

✓ Pass — Event is in the future and within 31 days. Execution pauses until start_time, then notifications fire.

✗ Fail — Event date is in the past or exceeds 31 days. Step fails immediately.

SLA escalation — escalate if not resolved within 4 hours

Support ops · Delay For · Dynamic amount from field

DYNAMIC VALUE

A ticket is created. The SLA hours come from the ticket's sla_hours field rather than a fixed number, allowing different tiers to have different SLAs.

Configuration

delay_typeFOR

time_amount{{ input.sla_hours }}

time_unitHOURS

✓ Pass — sla_hours is a valid number. Workflow pauses and escalation fires after the SLA window.

✗ Fail — sla_hours is missing or non-numeric. Step fails immediately.

Workflow Diagrams

Pattern 1 — Simple timed pause

Trigger → Delay (For) → Action | fail → stop

Trigger fires, execution pauses for the configured duration, then resumes at the action with the original payload.

Pattern 2 — Dynamic timestamp wait

Trigger → App Action → Delay Until {{ date }} → Notify

App action fetches an event record with a date field. Delay Until waits until that exact moment before triggering the notification.

Pattern 3 — Multi-step drip sequence

Trigger → Email 1 → Delay 3d → Email 2 → Delay 7d → Email 3

Multiple Delay nodes pace a drip sequence. Each delay is within the 31-day cap individually — chaining to exceed 31 days total is not supported.

Frequently Asked Questions

Configuration & Modes

What is the difference between Delay For and Delay Until?+

Delay For pauses for a relative duration from now (e.g. "wait 2 hours"). Delay Until pauses until a specific point in time (e.g. "wait until 2025-06-01 09:00").

Use Delay For when the wait duration is fixed or relative. Use Delay Until when you have a specific timestamp from your data.

Can I map dynamic values into the delay fields?+

Yes. Both time_amount and target behave like Slate text fields. You can enter values manually or map references from upstream nodes (e.g. {{ input.event_date }}).

If the mapped value cannot be converted to the expected type at runtime, the step is marked as FAILED.

Where is timezone configured for the Delay node?+

Timezone is not configured at the node level. It is resolved from the user profile-level timezone setting. All internal scheduling and storage uses UTC.

What is the maximum delay duration?+

31 days from execution time — this is a hard cap enforced at runtime (not during test runs). If a Delay Until target exceeds 31 days, the workflow fails immediately and all subsequent steps are skipped.

Chaining multiple Delay nodes to exceed this limit is not supported and may cause runtime errors.

Behaviour & Edge Cases

What happens if the Delay Until target is in the past?+

The if_past setting controls this. If the date is within the configured tolerance (e.g. up to 1 day in the past), execution continues immediately. If outside tolerance, the step fails. The system never waits for a past date.

What happens if the workflow is cancelled while a delay is in progress?+

The node transitions to CANCELLED state. The system attempts to remove the job from the queue. When the resume time arrives, the node checks the DB state — if CANCELLED, execution is dropped (no-op). Downstream steps are never triggered.

Is the resume time exact?+

Not guaranteed to be sub-second precise. Resume timing depends on the scheduler polling interval. The actual_delay_seconds metadata field records the real elapsed time, which may differ slightly from the target.

What data is available to downstream nodes after a delay?+

The original workflow payload is fully preserved. Additionally, a _meta.delay block is injected with scheduled_at, resume_at, resumed_at, and actual_delay_seconds — all available for downstream mapping.

Limits & Future Scope

Can I use the Delay node inside a Repeater or parallel branch?+

Not in the current release. Support for Delay inside Repeater blocks and path branches is planned for a future version.

Is there a "Delay After Queue" feature?+

Not yet. Delay After Queue is a deferred feature not included in the current release. It will be implemented separately due to backend complexity.

Ready to build smarter workflows?

Add a Delay node to your workflow and start controlling exactly when your automations run.

Get started free →