Skip to main content
Workflows can pause execution to wait for time delays or external events. During waits, the worker suspends execution and no compute resources are consumed.

Why use waits?

Waits enable workflows to:
  • Delay execution - Wait hours, days, or weeks between steps
  • Coordinate with external systems - Wait for webhooks, approvals, or user actions
  • Implement timeouts - Fail gracefully if events don’t arrive
  • Save costs - No compute consumed while waiting

Types of waits

1. Time based: wait_for

Pause for a duration:
Available time units:

2. Timestamp-based: wait_until

Wait until a specific datetime
Timezone handling:

3. Event-based: wait_for_event

Wait for an external event:
With timeout:

Wait behavior

Worker suspension

When a workflow waits:
  1. Worker suspends execution - Workflow state is saved
  2. No compute consumed - Worker is freed to handle other workflows
  3. Orchestrator tracks wait - Schedules resumption
  4. Workflow resumes - Worker picks up from where it stopped

Short vs long waits

Short waits (≤10 seconds):
  • Worker sleeps inline (doesn’t suspend)
  • Slightly more efficient (no orchestrator round-trip)
  • Configurable via POLOS_WAIT_THRESHOLD_SECONDS environment variable
Long waits (>10 seconds):
  • Worker suspends and is freed
  • Orchestrator schedules resumption
  • Essential for hours/days/weeks

Publishing events to resume waits

From within a workflow

From external systems (API)