Workflow delays

A Delay Step waits before continuing its route. Use it for follow-ups, cooldowns, short synchronization windows, or scheduled checks relative to the Trigger.

Configure a Delay

1. Select an add point in the Workflow.
2. Choose Delay.
3. Enter the delay in seconds.
4. Save the Step and verify the route with a short test delay.

The allowed value is from 1 to 2,592,000 seconds—up to 30 days. FastHook stores whole seconds.

Runtime behavior

When execution reaches a Delay, FastHook records the Step start time and returns the run to the queued state. Long waits are scheduled in queue chunks of at most 86,400 seconds while preserving the original start time, so retries do not restart the entire delay.

After the remaining time reaches zero, the Delay succeeds, passes its input through unchanged, and the normal route continues.

What a Delay does not do

• It does not change the data passed to the next Step.
• It does not poll a provider for a new value.
• It does not guarantee delivery at an exact wall-clock millisecond; queue processing adds normal scheduling latency.
• It does not create a recurring schedule.

Design considerations

Data freshness

The Workflow continues with the stored execution input, not a fresh provider lookup. Add a lookup Action after the Delay when the next decision must use current provider state.

Permissions and resources

Provider access can change during a long wait. An account may be revoked or a selected record may be deleted before the next Action executes, so handle that Action's error explicitly when appropriate.

Idempotency

Delayed Actions can still be retried. Use provider idempotency features or a preceding lookup/filter when duplicate side effects would be harmful.

Workflow edits

Audit records the Workflow version associated with the run. Do not assume an in-flight delayed run will behave like a new event processed by the latest graph version.

Troubleshooting

If a run remains queued, check the Delay Step start time and configured seconds before diagnosing a queue failure. An invalid value fails with workflow_delay_invalid; queue retry exhaustion appears as a terminal delivery-exhausted error.

See Runs and errors for status inspection and Error handling for recovery routes.