Run now

Any deployed task can be run on demand, whether or not it has a schedule. In the dashboard, use the run button on the agent row. From the CLI:

# Start a run and return immediately
afy agents run nightly-report

# Pass input and block until it finishes
afy agents run nightly-report --payload '{"date":"2026-07-17"}' --wait

# Or read the payload from a file
afy agents run nightly-report --payload-file ./input.json --wait

• --payload / -p takes inline JSON; --payload-file / -f reads it from a file. Use one or the other, not both.
• --wait blocks until the run ends and exits 0 on success, 1 on failure — which makes afy agents run ... --wait usable as a CI step.

A manual run is not a schedule event: it does not consume, shift, or record against the schedule. The next scheduled run happens exactly when it would have anyway.

Pause and resume a schedule

Pausing stops scheduled runs without touching your aetherfy.yaml or the agent itself. Manual runs still work while paused. In the dashboard this is the pause control on the agent row; the next-run cell then reads Paused.

# Stop scheduled runs; manual runs still work
afy agents schedule pause nightly-report

# Resume — the next run is the next future occurrence
afy agents schedule resume nightly-report

Overlaps and missed windows

A schedule is a heartbeat, not a work queue. Occurrences that cannot run are dropped, never queued:

• Overlap. If the previous run is still going when the next one is due, that occurrence is skipped. Runs never stack up, and a task that occasionally overruns its interval cannot snowball into a pile of concurrent machines.
• Missed window. If an occurrence could not be evaluated in time, it is recorded as missed and the schedule skips to the next future occurrence. There is no catch-up burst.

If you need every single occurrence to be processed, a schedule is the wrong tool — use a durable queue and let a task drain it.

Run history

The dashboard shows a RUN HISTORY drawer per agent, with columns WHEN · TRIGGER · STATE · DURATION · LOGS. The CLI shows the same list:

# Recent runs, newest first (default 20, max 100)
afy agents runs nightly-report --limit 50

# Logs for one specific run
afy logs nightly-report --run <run-id>

History covers scheduled and on-demand runs — the TRIGGER column reads scheduled or manual. Workers spawned by a parent agent are not listed here; they belong to the parent's history.

Run states

Runs are briefly QUEUED and DEPLOYING on their way to ACTIVE.

Last-fire badges

Next to the schedule, the dashboard shows what happened at the most recent occurrence:

Per-run logs

Every history row deep-links to that run's logs in the dashboard, filtered to just that run. From the CLI, pass the run id from afy agents runs to afy logs --run. This is the fastest path from "last night's run failed" to the traceback that explains it.

Limits and billing behavior

• A schedule adds no charge of its own. You pay for the runs' compute, and your spend limit applies to it like any other usage.
• Scheduled tasks are agents, so how many you can have is bounded by your plan's agent allowance — not by a separate schedule quota.