Walk this list top to bottom — the causes are ordered from most to least common. Each one tells you exactly what to check.

1. The automation is turned off

Open the automation and confirm it's set to Active. A draft or paused automation never fires.

2. The keyword didn't match

Matching is stricter than it looks:

• Comment triggers match the keyword as a whole word. LINK won't fire on "linktree".
• DM triggers match the whole message exactly. START won't fire on "I want to start".
• Story-reply triggers match the whole reply exactly too. YES won't fire on "yes please". And if you meant the automation to answer every reply to your stories, clear its keywords — a story trigger with keywords only fires on those keywords.

Re-read Triggers and test with a comment or DM that matches precisely. Case only matters if you turned on the trigger's Case sensitive setting — otherwise it's ignored.

3. You tested twice with the same account

Each contact can trigger a given automation only once every 24 hours. If you commented your keyword, got the DM, then commented again from the same account to double-check, the second attempt is silently skipped — that's the cooldown working, not the automation breaking. It only blocks starting the automation again; a conversation already in progress keeps going. Test again from a different account, or wait out the 24 hours.

4. The messaging window had expired

A DM can only send inside an open window — 24 hours from the person's last DM, or 7 days from their comment. If too much time passed, the run is marked expired and won't send. This is the most common reason a "working" automation goes quiet on older conversations. See The 24-hour window.

5. You hit a plan cap

Each plan has a weekly cap on automation sends and form submissions together, so a busy form can use up the same budget your DMs draw on. Once you reach it, new conversations stop starting until the week resets or you upgrade — though a conversation already mid-flow is allowed to finish, so you may still see some replies go out after hitting the cap. Check Limits & plans and your current usage.

6. A backlog of locked form responses is spending the new week's budget

This is the one that surprises people, because it looks like the cap didn't actually reset.

Form submissions are never refused. When you go over the weekly cap, the responses that arrive after it are still stored, but they're stored locked — you can see they came in, not what they say. At the weekly reset those locked responses unlock, oldest first, and unlocking is served before any automation. So the new week's budget is spent on clearing the backlog first, and your automations only start firing again once it's cleared.

The consequence: if you locked 900 responses on a plan with a 1,000 cap, Monday's reset spends almost the whole week's budget releasing them and your automations stay quiet for most of the week. If you're locking more responses per week than your cap covers, the backlog never clears on its own and your automations stay quiet indefinitely.

Two ways out: upgrade, which unlocks the entire backlog immediately and frees the week's budget for automations, or reduce what's coming in (see the anti-spam notes in Share your form if the volume is junk). Your locked count is on Settings → Billing and on each form's responses page.

7. The contact is excluded by an audience rule

Automations skip a contact when an audience rule says to. This happens if the contact holds a tag you've set to exclude from automations, or if the automation uses an include allowlist and the contact isn't on it. Open the automation's trigger settings and the contact's tags to check.

8. The contact is whitelisted

Contacts on your whitelist are skipped by every automation. Skip DMs covers story-reply automations too, since a story reply is a DM. If you (or an "ignore contact" action in the inbox) added them, automations won't fire for them. Check Manage → Whitelist.

9. Another automation fired first

Only one automation runs per incoming message — the first one that matches, in your automations' priority order. And if the contact already has an open conversation with one automation, a new inbound DM continues that conversation instead of starting a different automation. If you expected a different automation to fire, this is usually why.

This is the usual answer for a story automation that stayed quiet. A reply to your story arrives as an ordinary DM, so a catch-all DM automation matches it as well — and if that DM automation sits higher in your priority order, it wins and your story automation never runs. The fix is Skip story replies: open the DM trigger and turn it on, so that automation leaves story replies to the story automation. It's off by default. Reordering is not the answer here — dashboard-built automations all share one priority and the tie goes to the older automation, so the DM catch-all you already had wins, and priority order is only settable over the API (priority_order on PATCH /api/automations/:id). If it's the other way round — a DM automation that used to answer story replies and now doesn't — someone turned that setting on. See Triggers.

10. Automations are suspended for being over your connection cap

If your workspace stays over its Instagram-connection cap past the grace period, automated replies are suspended until you get back under the cap (or upgrade). Check Connections and your plan.

11. Your workspace is suspended

If big has suspended your workspace, no new automation run starts and nothing new leaves the send queue — for every automation and every connected account at once. That is different from cause 10 above: the connection cap is a state you clear yourself by getting back under it, while a suspension is applied by a person and lifted by one. The workspace owner is notified with the reason when it happens, so check the bell and the owner's email. See If your workspace is suspended.

12. The Instagram connection needs reconnecting

If the connection shows an error or expired state, re-run Connect Instagram to re-authorize.

13. You tested with your own account

Instagram won't deliver an automated DM from your account to itself. Test from a different Instagram account.

14. The send was queued and gave up

The first thirteen causes all stop a send before it's attempted. This one is different: the automation matched, the run started, big accepted the message — and it still never arrived. That's the send queue.

Every outgoing DM goes onto a durable queue rather than straight out to Instagram, so a hiccup on Instagram's side doesn't lose the message. A queued send is in one of three states:

A successful send leaves no row at all — the queue entry is deleted and the message itself becomes the record. So an empty queue is the healthy state. Anything sitting in the queue is either in flight or stuck.

A send retries with a growing delay (never more than 15 minutes between attempts) and dead-letters after 5 failed attempts. It also dead-letters immediately, without spending attempts, when retrying is pointless:

• the Instagram connection isn't usable — disconnected, deauthorized, or its stored token can't be decrypted (this one means "reconnect the account");
• the 24-hour window closed while the message waited — big won't send into a closed window, so a message that sat in backoff too long is dropped rather than rejected by Instagram. See The 24-hour window;
• an earlier step in the same conversation dead-lettered — the chain is broken, so the steps after it are stopped rather than sent out of order.

Two things follow from this that are easy to misread:

• A one-step automation that dead-letters looks identical to one that never fired. Nothing arrives, and the run itself may still read as active. Check the run's status against Run statuses before assuming the trigger didn't match.
• A multi-step automation can deliver its first message and nothing after it. That's the chain-halt rule above, not a broken graph.

Queue state is per connection, on the Connect page — and readable programmatically at GET /api/connections/:id/send-queue, which returns the pending and dead-letter counts plus the most recent failures with their error codes. The companion GET /api/connections/:id/health shows the two flags that stop sends without any other signal, send_backoff_until and auto_reply_suspended. See Connection diagnostics.

Dead-letter rows are swept after a retention period, so investigate a silent failure while it's recent.

Working this list from the CLI or an AI client

Everything above is readable without opening the dashboard, which matters when you've handed the question to an agent. Three surfaces expose the same data under different names — the big CLI, the local MCP server (big mcp, tools prefixed big_), and the remote MCP server (unprefixed tools). Pick the column you're connected to:

Start with the one-call rollup. It needs no scope and answers causes 5, 6, 10, 11 and 12 together, so it rules out five of the fourteen before you ask a second question.

Two things no surface here will tell you. Keyword matching (cause 2) can only be judged by reading the automation's keywords against the exact text that was sent — no tool replays a match. And the Activity feed, which lists inbound events as matched or no match, is dashboard-only: if the rollup and the runs both look healthy and you still can't tell whether the message ever reached a trigger, open Activity in the app. An agent that has ruled out the fourteen causes above should say that rather than keep guessing.

Still stuck?

If you've ruled out all of the above and the automation still won't fire, reach out to support with the post or conversation and roughly when you expected it to run.