Running tests
Execution lifecycle and states
Every state an AEON execution passes through — queued, provisioning, running, verdict, archived — and what to do when one stalls.
5 min read
State machine
texttext
queued -> provisioning -> running -> verdict -> archived | | | | | +-> aborted (user or policy) | +----------------> failed (lane or build error) +-----------------------------> cancelled (before dispatch)
| State | Meaning | Typical duration |
|---|---|---|
| queued | Waiting for a lane matching your constraints | seconds to minutes |
| provisioning | Lane flashing your build, SDR calibrating | 20-90 s |
| running | TTCN-3 engine executing the case list | case-dependent |
| verdict | Aggregating verdicts, generating report | under 10 s |
| archived | Logs, PCAPs, report retained per policy | 30-365 days |
When a run stalls in queued
- Your constraints may be too narrow — drop --sdr or --region and let the scheduler pick.
- Check quota: aeon quota show.
- Check lane availability: aeon lanes list --available.
Inspect and control
bashbash
aeon exec list --state running aeon exec describe --id 4821 aeon exec cancel --id 4821 --reason "wrong build tag"
Run this against a real SDR lane
The tester is a service, not a box. Push a build, reserve a lane, get a verdict.