# Delays, snooze and waits

> How APIANT automations pause for a number of seconds or snooze until a date and time, how parked runs resume, where waits are not allowed, and how to wake or cancel snoozed runs.

An automation can stop partway through a run and continue later: after a fixed delay, at a date and time, or when something else happens. A waiting run is **parked**. Its progress is saved, nothing holds it in memory, and it survives platform restarts.

## Delay actions

The System app has three actions that park a run until a time:

| Action | Inputs | Use |
|---|---|---|
| Pause for a specified number of seconds | Seconds to pause, a setting (default 1) | A fixed delay, such as waiting 60 seconds for an app to finish processing |
| Pause for a random number of seconds | Min and max seconds to pause, settings (defaults 1 and 2) | Spreading out calls so they do not arrive at the same moment |
| Snooze automation | `value`, `modifiers`, `tz_offset` | Waiting until a date and time, or until an offset from one |

Ask for them in plain English: "wait 10 minutes, then send the follow-up", "hold this until two hours before the appointment starts".

The System app needs no connection. There is no separate date and time app for these actions.

### Snooze inputs

| Input | Accepts | Examples |
|---|---|---|
| `value` | A date and time, natural language, or Unix epoch seconds. Blank means now. | `{{ trigger['Appointment Start Time'] }}`, `in 3 days`, `next friday`, `now`, `1767225600` |
| `modifiers` | Adjustments applied to `value`, using `d`, `h`, `m` and `s`, separated by spaces | `-2h`, `+1d -30m` |
| `tz_offset` | Blank uses the server's timezone (generally UTC) for a value with no timezone. `ACCOUNT` converts a UTC value to your account's timezone. `ACCOUNT_UTC` converts a value in your account's timezone to UTC. A number is an offset in seconds. | `ACCOUNT_UTC` |

Leave `tz_offset` blank when the value already carries a timezone, such as an ISO 8601 timestamp with an offset. An offset entered for such a value is still applied.

Examples:

| Goal | `value` | `modifiers` |
|---|---|---|
| Wait 30 minutes | `now` | `+30m` |
| Two hours before an appointment | `{{ trigger['Appointment Start Time'] }}` | `-2h` |
| Three days after signup | `{{ trigger.body.signed_up_at }}` | `+3d` |

If the computed time is already in the past, the step does not wait and the run continues immediately.

### What a delay step outputs

All three actions declare `Target at`, `Resumed at`, `Waited seconds` and `Timed out`. After a run has actually waited, only `Resumed at` and `Timed out` hold values; `Target at` and `Waited seconds` are empty. Use `Resumed at` to confirm the step waited, and keep the target time in the step that computed it if later steps need it.

## How a parked run resumes

1. The run parks at the delay step. Its status in Execution History becomes **snoozed**.
2. At the target time, APIANT picks the run up. A sweep also checks for due runs every 30 seconds, so a resume can land up to about half a minute after the target.
3. The run continues with the step after the delay step, with the outputs of earlier steps intact.

### When the automation is turned off

Turning an automation off does not cancel its parked runs. They are kept, and they resume on the next sweep after you turn the automation back on, even if their target time passed while it was off. Pending automatic retries are the exception: turning an automation off removes them. See [Error handling and retries](/docs/automations/error-handling#automatic-retries).

## Where a run cannot wait

A delay step fails the run, with an error, in three places:

| Placement | Why | Instead |
|---|---|---|
| An automation with a polling or Collector trigger | The steps run inside the trigger's per-record loop, which cannot pause | Use a webhook, manual or scheduled trigger |
| A parallel branch | A branch cannot be resumed on its own | Put the delay before or after the parallel step |
| An ordinary automation called synchronously by another | A synchronous child runs inside its caller and cannot pause | Build the target as a subroutine, or launch it asynchronously |

A delay inside a subroutine, a condition or a loop works. See [Subroutines and calling automations](/docs/automations/subroutines).

The polling restriction is the one most often hit. "Poll for new rows, snooze until each row's date, send a reminder" saves without complaint and then fails at the snooze step on every run. Split it in two: the polling automation launches a second automation in the background, passing the record and naming a latch group, and that automation snoozes. See [Subroutines and calling automations](/docs/automations/subroutines#synchronous-and-asynchronous-calls).

## Waking or cancelling snoozed runs

In Execution History, open a run and filter its records to **Snoozed**. Two buttons act on every snoozed record of that run:

- **Wake up all snoozed…** moves the target time of Snooze and Pause waits to now, so they resume on the next sweep, within about 30 seconds. Form and approval waits are not affected.
- **Cancel all snoozed…** removes every wait on that run's records, including form, approval, latch and retry waits, so the records never resume. The browser asks you to confirm, and this cannot be undone.

From Claude Code, you can also ask Claude to cancel the snoozed runs of an automation, or one snoozed run. Cancelled runs are marked **halted** and never resume. The assistant in the app cannot cancel snoozed runs; use the Execution History buttons instead.

With the Snoozed filter selected, the two buttons appear above the run's record list.

## Other kinds of wait

The same parking applies to steps that wait for something other than a time. Each has its own page:

| Wait | Continues when | Timeout |
|---|---|---|
| Await form submission | Someone submits the form | Optional variant with a timeout |
| Await human moderation | Someone approves or denies the item | Optional variant with a timeout and a default result |
| Wait for latched automations | Every launched child automation has finished | Optional on the engine step |
| Snooze automation, Pause | The target time arrives | Not applicable |

See [Hosted forms](/docs/interfaces/forms), [Human approval](/docs/interfaces/approvals) and [Fan-out and fan-in](/docs/automations/fan-out-fan-in).

A run that fails with a retryable error is also parked while it waits for its next automatic attempt. See [Error handling and retries](/docs/automations/error-handling).

## Troubleshooting

| Symptom | Likely cause | What to do |
|---|---|---|
| The run fails at the snooze step with "not allowed inside a parallel branch or execute-automation child run" | The delay is in a parallel branch or a synchronously called automation | Move the delay, or change how the automation is called |
| The run fails at the snooze step on every polled record | The automation has a polling trigger | Move the waiting into a separate automation launched asynchronously |
| The step did not wait | The computed time was already past | Check `value`, `modifiers` and `tz_offset` against the source data |
| Runs stay snoozed past their time | The automation is turned off | Turn it on, or cancel the runs |

## Next steps

- [Fan-out and fan-in](/docs/automations/fan-out-fan-in)
- [Scheduled triggers](/docs/automations/triggers/schedules)
- [Execution history](/docs/runs)
- [Hosted forms](/docs/interfaces/forms)