Run statuses
A run is one contact's journey through one automation. Every time a trigger matches a person who doesn't already have a run open, big creates one and walks it through the automation's graph. big runs <automationId> and GET /api/automations/:id/runs print each run's status; here's what the five values mean. To look at one run — its status, why it halted, the node it is parked on, how many actions it took, and when it last heard from the contact — run big run:view <id> (or GET /api/runs/:id, big_run_get on the local MCP server, or get_automation_run on the remote one) with an id from that list. The list holds at most the 200 most recent runs, and has no contact filter: find one person's run by its contact_id (big runs <automationId> --json).
The five statuses
| Status | Open? | Means |
|---|---|---|
active | yes | The run is working — walking the graph and queueing sends. |
awaiting_reply | yes | The run is parked at a branch, waiting for the contact's next DM to decide which way to go. |
completed | no | It reached the end of the graph. Nothing more will happen. |
expired | no | The messaging window closed before it finished. |
halted | no | A safety guard stopped it. halt_reason says which one. |
The three terminal statuses are final: a run never leaves them, and a new trigger from the same person mints a fresh run rather than reviving the old one.
awaiting_reply is the one to understand
When an automation branches on what the person says, the run can't continue until they say something. It parks in awaiting_reply, remembers which branch node it's sitting on, and waits. Their next inbound DM resumes it from exactly that point.
This matters because of the one-open-run-per-contact rule: a contact can have at most one open run per connected account, and active and awaiting_reply both count as open. So while a run is parked waiting for a reply, the contact's next DM continues that conversation rather than starting a different automation — even if their message would have matched another automation's keyword perfectly. The same holds for a comment: a matching comment from someone mid-conversation is skipped rather than starting a second run, and once their open run's window has closed the comment starts its automation as normal.
That's usually the answer to "why did my other automation not fire for this person?" — see Fix an automation that didn't fire.
expired
Instagram only lets you DM someone inside an open window — 24 hours from their last DM, 7 days from their comment. If the window closes before the run finishes, the run is marked expired and stops. big does not queue the remaining messages for later, because Instagram would reject them.
The window is re-anchored by every new message from that person, so an active back-and-forth stays open. See The 24-hour window.
halted
halted means big stopped the run deliberately, as a guard rather than an outcome. Every halted run records why in halt_reason, which big runs prints beside the status, big run:view prints on its own line, and GET /api/runs/:id, big_run_get and the remote get_automation_run return as a field. A run halted before October 2026 has no reason recorded and reads null.
halt_reason | What happened |
|---|---|
choices_typed_twice | The commonest one. The run was waiting at a step with quick-reply choices, and the contact typed a reply instead of tapping one. big re-sends the choices once; when they type a second time instead of tapping, the run ends. A choices step with its own path for a typed reply (a connection out of the step on the dashboard canvas) follows that path instead and never halts here. |
actions_cap | The run reached the automation's max_actions_per_run. A choices step re-sent after a typed reply counts as an action too. |
weekly_cap | The weekly plan cap refused the send that would have started the conversation. A conversation already in flight is allowed to finish, but a run that can't take its first step is halted rather than left hanging. This includes the week after you go over the cap: a backlog of locked form responses is released before any automation runs. See Plans and cause 6. |
send_not_queued | A reply couldn't be written to the send queue. big stops the run there instead of skipping ahead, and that step is not counted against your weekly usage. |
automation_deleted | The automation was deleted while the run was open. |
automation_not_dm | The contact replied to a run whose automation no longer sends as a DM, because its trigger was changed to comment. A comment automation sends text only and never waits for a tap. |
loop_cap_no_exit | A follower re-check loop ran out of tries and the branch had no "after N tries" (loop_exhausted) path to route into. |
no_branch_arm | No arm of a branch matched the reply, and the branch had no otherwise. A step document always has one, so this comes from a raw graph. |
no_current_node | A reply arrived for a run that was parked on no step. |
unknown_node | The run's graph holds a step type this version of big doesn't know. |
A halted run is not a bug report on its own: the step limit, the plan cap and the choices re-send are working as designed. A send_not_queued, no_current_node or unknown_node you can't account for is worth reporting.
completed
The run walked to the end of its graph. Note that "completed" describes the run, not delivery: a message can be queued successfully and still fail on its way to Instagram. If a run reads completed but nothing arrived, check the send queue — cause 14.
Look at one run
big run:view <id> prints one run in full:
run_1 [halted: choices_typed_twice]
halt reason: choices_typed_twice (what it means: big docs:read automations/run-status)
automation: …
contact: …
connection: …
current node: the branch it is parked on (— once it ends)
actions: 2
started: …
last inbound: the contact's last DM into this run
last advanced: the last step it took
expires: when the messaging window closeslast inbound against expires is usually the answer to "why did this contact stop getting replies": an awaiting_reply run whose contact never wrote back runs out its window and becomes expired, and a halted run names its reason on the first line.
The run's context appears only with --json. It is big's own bookkeeping, not anything the contact typed:
| Key | Holds |
|---|---|
trigger_event_id | The id of the DM or comment that started the run. A second delivery of the same message never starts a second run. |
trigger_kind | dm or comment. |
loop_attempts | Per branch step with max_attempts, how many re-check tries the contact has used. |
chip_reprompts | Per choices step, set once big has re-sent the choices after a typed reply. A second typed reply there halts the run with choices_typed_twice. |
It needs automations:read.