# Signals, schedules and waits

Distinguish a durable wait inside a run from a schedule that starts new runs.

A wait suspends progress inside one run. A signal supplies durable input to that run. A schedule is a separate server resource that starts runs on a cadence.

## Signals

An AWL workflow declares the signals it receives. A wait consumes a named signal with its declared payload type. Sending the same signal twice records two deliveries. Deduplicate repeat sends in the application when needed.

A send declaration describes a signal sent to another workflow. The target is a workflow id, or the declared child target form. The declaration and the receive contract are separate.

## Timers and waits

Sleep uses a durable timer. A timed wait needs a timeout path as well as its received-value path. An ordinary child call waits for its result; spawn starts without waiting and cannot bind a result.

A workflow deadline ends the run. A timeout passed to the one-motion run command only bounds the client's wait. These have different effects.

## Schedules

Schedules have interval or cron triggers. They also declare what to do when runs overlap and when ticks were missed. Their owning namespace is fixed at creation.

There is no schedule CLI subcommand in the current command tree. Use the HTTP or gRPC schedule API. See [schedule operations](/aion/operations/schedules/) for the complete route set and an example.

## Workloops

A workloop keeps one continuing identity, carried values and declared health checks. It closes an iteration by routing to start. A schedule starts a separate workflow execution at each firing.

Read [AWL waits](/aion/reference/awl-waits/) and [workloops](/aion/concepts/workloops/).