Wait

Overview#

Wait for a specified duration before continuing execution.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

Working examples#

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

1. Pause before a follow-up#

You will build: The message released after a short pause.

Makes timing an explicit workflow step. The orchestrator persists the wait instead of holding a process open.

Open this template and adapt the labels, prompts, or credentials to your own workflow.

2. Add a provider cooldown#

You will build: A controlled pause between provider calls.

Reduces accidental burst traffic. A fixed duration is easier to reason about than hidden client-side sleeps.

Open this template and adapt the labels, prompts, or credentials to your own workflow.

3. Hold a scheduled review#

You will build: The packet continues at the intended review time.

Keeps scheduling logic inside the graph. Durable orchestration resumes the run after worker restarts.

Open this template and adapt the labels, prompts, or credentials to your own workflow.

Ports#

• Input: Input (input): any, optional, single.
• Output: Output (output): any, optional, single.

Inspector#

• Duration: key duration; number; range: 0 to 604800000; default: 1000.

Behavior#

• Input requirement: No inbound value is required by the contract.
• Execution: Handled by the orchestrator using delay.
• Timeout: 1000 ms by default (0 to 604800000 ms).

Cost#

No metered provider or compute cost is assigned to this node.

Security#

• No credentials are used.
• The node has no external side effects.

Retry#

Retry and resume behavior is owned by the workflow orchestrator rather than a nested node retry loop.

Production checklist#

• Test the happy path and one malformed or empty input.
• Keep credentials out of prompts and published graph configuration.
• Set a timeout and retry policy that matches the operation's side effects.
• Name the final result so a runner can tell what success looks like.