Zapier Zap not running? Check triggers, holds and errors

Why is my Zapier Zap not running?

Start with one event, not the whole automation

Write down the Zap name, source item ID, event time and time zone, expected destination and current symptom. Use the same item throughout the investigation. “The lead did not arrive” is too broad if one person is looking at a form submission, another at an email and a third at a CRM contact.

1. Open Zap History and narrow the dates and Zap to the expected event.
2. If a run exists, record its ID and inspect the first affected step.
3. If there is no run, inspect the trigger account, event and selected folder, list or form.
4. Check the destination directly for an existing result before testing or replaying.

Record an unknown as unknown. An empty History search can also reflect the wrong filters or time window; it does not establish a vendor outage.

No run in History: what should I check?

Confirm the Zap is on, the intended app account is connected, the trigger event matches the record type and its options point to the correct resource. For a new-item trigger, an item created before activation is not a valid test of a new event. Create one clearly identified item in an authorised test context after activation.

An editor trigger test can retrieve sample records; that alone does not establish that a new live event completed the workflow. Compare the configured trigger with the actual event. The trigger troubleshooting guide gives app-specific checks, and Zapier’s trigger explanation distinguishes testing from live data.

A polling trigger checks periodically; an instant trigger receives a notification from the app. The actual interval and account configuration matter. In this guide’s assumed 15-minute schedule, a 12:02 item checked at 12:07 is still eight minutes before the next assumed 12:15 poll. That is a timing example, not a delivery guarantee or an observation from Zapier. Allow for processing and app-specific behavior before classifying the event as missed.

A run exists: read the step, not just the headline

Run-level and step-level statuses can differ. A later step showing Filtered while an earlier step waits is not, by itself, proof of a failed filter rule. Read the surrounding steps. See the run-status definitions for the exact status you see.

Why did the test work but the filter stop a live run?

Inspect the field in the actual run, not only the sample used in the editor. A live record may omit a value, send it through another field or use a changed field name. Check the condition’s data type and whether the intended logic needs all conditions or any condition.

For the fictional SR-002 case below, a territory field is empty while the requirement is UK. The useful question is whether this record should qualify and where its territory should come from. Removing the filter would change the business rule. Correct the source data or mapping when that is the cause, then review the intended behavior with a representative new record.

Zapier’s filter checks cover missing fields and stale mappings. If a later action receives no value, compare its Data In with the preceding step’s Data Out and review the field-transfer checks.

Why is the run on hold or failing at an action?

Read the held reason before changing the plan. Documented causes include disconnected app accounts, usage or plan boundaries, billing problems, flood protection and enterprise app policies. Ask the appropriate connection or account owner to address the actual cause. An app policy is an administration decision; adding another connection does not establish that the app is permitted.

For an action error, capture the message and inspect the affected step’s input and available logs. A required-field error, an authentication problem, a permission refusal and a rate limit require different checks. Use held-run guidance or action-error guidance for that symptom.

If a request timed out, check the receiving app for a result before sending it again: an uncertain response does not prove that no record was written. Keep the source item, attempt and returned destination ID together. That investigation is especially useful where the action creates a new record each time.

Should I replay errored steps or the entire Zap?

The replay menu has different scopes. Errored steps retries the failed work; Entire Zap creates a new run using prior trigger data and executes the current published workflow, including previously successful steps. Changing a draft is not the same as publishing that workflow.

Manual replay on Free is limited to errored runs; other statuses and entire-run replay have paid-plan requirements. Check the current plan and menu rather than assuming every status has the same recovery route. Autoreplay does not automatically recover held runs. Failed-step recovery also does not re-evaluate Filter and Paths steps. See how replay works and the replay controls and plan boundaries.

Successful steps in an entire replay can consume tasks again. Review the scope, published version and expected side effects before starting with one authorised test case. Draft and version guidance explains why the workflow you are editing may differ from the one a run used.

Five fictional cases: what would you inspect first?

These are editorial practice cases, not screenshots, account logs or measured Zapier results. The observed fields are assumed. Use them to explain the next check without treating every missing business outcome as a trigger failure.

For SR-005, a successful API action can still put a record in an unintended pipeline. Locate and reconcile that record with its owner; repeating the create action does not correct the selected destination.

What should I collect for support or the workflow owner?

Provide a narrow reproduction: Zap identity, relevant version, source item ID and time zone, run ID if present, first affected step, exact error and intended destination. Include whether an automatic retry is pending and whether the receiving app already has a result. Keep actual account observations separate from a suggested diagnosis.

Share only the fields needed through the approved support route. Logs can contain tokens, personal records or confidential payloads; remove those before placing material in a public forum or another tool. If the local checks do not explain the case, review Zapier’s and the connected app’s current service status and contact the appropriate support team. This guide makes no claim that an outage is occurring.

After recovery, record one expected event, its run and its verified destination result. Check for duplicates and explain any missed or excluded items. A green status alone is not a complete handover report.

Download the cases and your investigation worksheet

Download the five practice cases ↓

Download the investigation worksheet ↓

Download the replay review brief ↓

The worksheet leaves actual findings blank. For the wider buying decision, compare Zapier and Make workflow budgets or explore the Zapier profile. For a CRM destination, the record-identity and reconciliation guide helps define the handover.

Frequently asked questions