Zapier not triggering: polling, instant events and old records

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Identify what is supposed to start the Zap

Zapier has polling triggers, which periodically request data, and instant triggers, which receive events from the app. The trigger type comes from the integration and cannot simply be switched by the builder. Polling timing depends on the plan and configuration. Ordinary triggers handle new data, or updates where supported, rather than automatically importing records created before the Zap was enabled. Editor samples may differ from live payloads.

Our diagnostic recommendation is to separate three questions: was an eligible event created, did a Zap run begin, and did the intended destination action complete? Each has a different evidence source. A missing destination record alone does not prove a trigger failure.

A fictional new-ticket workflow

Assume a team wants one internal triage task for each newly created ticket in queue Q. The account also contains older tickets and another queue R. Create a synthetic ticket with a unique reference such as TRIGGER-DEMO-21 after the Zap is enabled. Record its source creation time, queue and connected account.

Do not use an older ticket already visible in the editor as the only automatic-run test. That may confirm mapping while saying nothing about whether a new live event qualifies. Likewise, a new ticket in queue R cannot validate a workflow configured only for Q.

A diagnostic sequence

1. Confirm the Zap is enabled and the configured trigger event matches creation or update as intended.
2. Check the connected account and any source scope such as queue, project, folder or list.
3. Identify whether the selected trigger is polling or instant and inspect the relevant current configuration.
4. Create the unique synthetic event in the correct source scope.
5. Inspect run history after the appropriate observation period and match the event reference.
6. If a run exists, inspect later steps, filters and destination outputs rather than continuing to blame the trigger.

Measure delay with distinct timestamps

For an illustrative investigation, record source creation at 10:00, run start at 10:03 and destination completion at 10:04. That produces a three-minute observed start delay and one further minute before completion. These are invented example times, not a Zapier benchmark or a plan promise.

Collect comparable observations before deciding whether delay is systematic. Include timezone information and avoid comparing a local clock in one app with a UTC value in another without converting them. A single slow destination request can make an instant trigger appear slow when only the final record is observed.

Keep historical imports separate

If the business needs 200 older tickets copied as well as new tickets, define a separate backfill plan with a fixed source list, duplicate policy and reconciliation totals. Do not repeatedly toggle a live workflow in the hope that ordinary triggering will become a complete historical import.

Our recommended acceptance contract for that backfill is the exact set of source IDs and one explained destination outcome per ID. A migration count belongs to the backfill exercise; it should not be confused with the latency of ongoing new events.

Escalate with useful evidence

If no run appears for a confirmed new event in the right scope, retain the event ID, trigger selection, connected account identifier, configuration and timestamps. Redact sensitive payloads. This makes the next investigation concrete without exposing credentials. Accept the live workflow only after new-event receipt and the final business action are both demonstrated in your environment. No account-level trigger test or delivery guarantee is claimed here.