Status lifecycle
How a ticket and its individual steps move from queued to a terminal state.
There are two levels of status, and they answer different questions.
- A ticket status says where the whole piece of work stands. It's what the runs list and the ticket header show.
- A step status says what one agent run is doing. It's what you see inside a ticket's timeline.
Ticket status
| Status | Meaning |
|---|---|
queued | Picked up, waiting for a worker or a concurrency slot. |
planning | The planner is writing the plan. |
awaiting_approval | The plan is written and waiting for you. Nothing is built until you approve it. |
awaiting_input | An agent hit a genuinely ambiguous decision and asked you a question. It's waiting on your answer. |
building | An agent is writing code. |
in_review | A pull request exists and is going through the review, QA and requirements gates. |
revising | A gate asked for changes and the reviser is addressing them. Expect several passes. |
merged | The PR was merged. Terminal, success. |
closed | The ticket was closed without merging. Terminal. |
failed | Something errored with no path forward. Terminal. |
cancelled | You cancelled it. Terminal. |
in_review and revising alternate until every gate passes — that loop is normal, not a
sign of trouble. A ticket that revised six times and merged is a success.
Step status
| Status | Meaning |
|---|---|
queued | Created and waiting for a worker (or for a concurrency slot). |
running | An agent is actively working on it. |
done | The step finished successfully. |
awaiting_input | This step asked you a question and is paused for the answer. |
merged | The merge step merged the PR. |
failed | The step errored, or a gate rejected with no path forward. |
cancelled | You cancelled it. |
Terminal step states are done, merged, failed, and cancelled.
Waiting on you
Two states mean Premia has stopped and needs a human. Neither is an error, and neither times out — the work resumes exactly where it paused.
awaiting_approval— plan approval is on for this project, so the plan needs your sign-off before any code is written. See Plan review.awaiting_input— an agent found a decision it shouldn't make alone (an ambiguous requirement, two defensible approaches with different consequences) and asked. Answer on the ticket in your issue tracker or in the dashboard, and it continues.
Both are billed the same as any other ticket: nothing is charged until a pull request exists.
Queued vs. paused
A run can sit in queued for two reasons:
- It's simply waiting for the next free worker.
- Your org is at its concurrency limit — the run is paced (re-queued), not failed, and starts automatically when a slot frees. You'll see a note on the run and, for ticket-triggered runs, a comment on the issue.
A third case looks similar but isn't: if you've set a spend cap and projected spend has reached it, new runs queue until you raise or clear the cap. See Plans, usage & limits.
Following completion
premia run "…" --wait and premia runs logs <id> --follow both block until the run
and all its children reach a terminal state, then exit with a code that reflects
success or failure — handy in CI.