A new lead fills out your form, but the contact never shows up in your CRM. A payment clears, but the row never lands in your spreadsheet. Or the data arrives, but half the fields are blank.
“Not sending data” usually means one of three things: the Zap never started a run, the run stopped partway (filtered, halted, held, or errored), or it finished but sent the wrong values. Zap history tells you which, and each has a different fix.
Quick diagnostic checklist
- Is the Zap turned on and published, and did it recently get turned off automatically?
- Does Zap history show a run for the record you expected? If not, the trigger never fired.
- If there is a run, what is its status: Successful, Filtered, Safely halted, On hold, Errored, Delayed, or Scheduled?
- Is the trigger instant or polling, and has enough time passed for the next poll on your plan?
- Was the record created before the Zap was turned on? Zaps only trigger on new data.
- Are the app connections used by the Zap still active, or marked expired?
- Did anyone rename a field, form question, or spreadsheet column that the Zap maps from?
- Has your account hit its task limit or its pay-per-task maximum?
Common causes of Zapier not sending data
1. The Zap was turned off after repeated errors
Zapier’s Zap is not running article explains that a Zap is switched off automatically when it errors on 95% of its runs and has run more than 20 times in the past 7 days. Team and Enterprise accounts get a grace period (24 and 72 hours respectively) before this happens. Turning it back on without fixing the errors that preceded the shutdown will only repeat the cycle.
2. The trigger has not seen the record yet
Triggers work in one of two ways. Instant triggers (marked with a lightning bolt in the editor) receive a webhook from the app the moment something happens. Polling triggers ask the app for new data on a schedule: every 15 minutes on the Free plan, every 2 minutes on Professional, and every minute on Team and Enterprise.
Zapier also deduplicates polled items by their unique ID, so an item it has already seen will not trigger again, and Zaps never trigger for records that existed before the Zap was turned on.
3. A filter or search step stopped the run on purpose
A run marked Filtered means a Filter step’s conditions were not met and nothing after it ran. Safely halted usually means a search action found nothing and the step was set to stop rather than continue. Zapier’s article on filters that are not working properly lists the usual suspects: empty fields that arrive as missing values, AND/OR logic set the wrong way, invisible trailing spaces (“Paid ” is not “Paid”), and dates or numbers in a format the condition does not expect.
4. An app connection expired or lost permissions
When the stored login for an app expires, actions start failing with authorization errors such as a 401 (unauthorized) or 403 (forbidden). The App Connections page marks expired connections with an icon and offers a Reconnect option to the connection’s owner.
5. Field mappings no longer match the source data
If someone renames a form question, deletes a spreadsheet column, swaps the trigger form, or adds a CRM custom field after the Zap was built, actions may receive blanks or the wrong value. Dropdowns that do not show a new pipeline, list, or custom field can often be refreshed with Load More, as described in this help article.
6. Runs are on hold
A run marked On hold is paused, not failed. Documented reasons include a disconnected account, reaching your task limit, using a premium feature your plan does not include, and app access policies on Enterprise accounts. Zapier also applies flood protection: when a polling trigger finds 100 or more new items at once, it holds them until you confirm they should run, per the Zap limits page. On paid plans, exceeding your task limit switches the account to pay-per-task billing rather than stopping, but Zaps stop once usage reaches three times the plan’s task limit.
7. A Delay step was interrupted
Runs waiting on a Delay step show as Delayed. According to Zapier’s common Delay problems article, if the Zap is turned off when the delay ends, or if you edit the Zap’s actions while runs are waiting, the steps after the delay will not run.
8. The receiving app rejected the data
The action ran but the destination app refused it. Typical responses are 400 (missing or badly formatted values), 404 (the record you are updating does not exist), 422 (a value is in the wrong format), and 429 (too many requests). The run shows as Errored, and the details are in the step’s logs.
Step-by-step troubleshooting
- Find the run, or confirm there is none. Open Zap history and filter by the Zap and a date range. Search for a value you know was in the missing record, such as an email address. No run at all points to the trigger (causes 1 and 2). A run with a non-successful status points to the step where it stopped.
- Read the status before opening any settings. Use the table below to tell a logic issue (Filtered, Safely halted) from an account issue (On hold) or a technical failure (Errored).
- For errored runs, open the step’s logs. Zapier’s error troubleshooting guide explains that the run details include a Logs tab with the HTTP status code, the error message, and the request that was sent. Compare what was sent against what the destination requires.
- For filtered runs, compare the actual data to the condition. Look at the data the trigger produced in that run. Check whether the field was missing, had extra spaces, or used different capitalization or date formatting. If a field is sometimes empty by design, add an explicit “exists” or “does not exist” condition instead of letting the comparison fail silently.
- Test every connection the Zap uses. On the App Connections page, open the menu next to each connection and choose Test connection. An “Expired” result means you should reconnect.
- Re-check mappings against a fresh sample. In the editor, pull in a new test record that reflects the current form or sheet layout. Open each action and look for fields showing old sample values or no value. Remap them, then use Load More on dropdowns that should include new options.
- Clear holds. If runs are held for task limits, check your usage and billing settings. If they are held by flood protection, review the batch before releasing it.
- Publish the fix, then replay. Replay reuses the original trigger data but runs it through the Zap’s currently published version, so fix and publish first. Replay one run, verify the result in the destination app, and only then replay the rest. Replaying a whole run re-executes earlier successful steps, which can create duplicates and uses tasks again.
Zapier run statuses and what they mean for missing data
| Status | What happened | Where to look next |
|---|---|---|
| Successful | Every step completed. | Data sent but wrong: check mappings and the destination record. |
| Filtered | A Filter step’s conditions were not met. | Compare trigger data to filter rules. |
| Safely halted | The run stopped on purpose, often a search with no result. | Search step settings and the searched value. |
| On hold | Paused for account, plan, or flood-protection reasons. | Connections, task usage, plan features. |
| Errored | A step failed. | The step’s Logs tab and HTTP status. |
| Delayed | Waiting on a Delay step. | Keep the Zap on and avoid editing actions until it finishes. |
| Scheduled | An errored run queued for Autoreplay. | Let the retry finish before replaying manually. |
Current definitions are on Zapier’s run status reference, which also covers Handled error, Needs review, Running, and Skipped.
Platform-specific notes
Autoreplay. On Professional plans and above, Autoreplay retries failed steps caused by temporary problems like a brief outage. It helps with 500-type errors and timeouts. It will not fix a 400 or 422, because the same bad data will fail the same way every time, and it does not replay safely halted runs.
Tasks. Per Zapier’s task rules, only successful action steps count. Triggers, Filter and Paths steps, Formatter and Delay steps, and actions that error or halt do not. If your task count looks low compared with the number of form submissions, that is a clue that runs are being filtered or failing.
Test data versus live data. The sample loaded during setup is only a snapshot. Live records can have empty optional fields or different formats, so test with your worst realistic case.
Sample workflow (hypothetical): The following is an illustration of how a lead-routing Zap is structured and where it typically loses data. It is not a description of a specific client project.
| Trigger | New form submission on a website contact form (instant trigger). |
|---|---|
| Applications | Form tool, a CRM, Google Sheets, and a team chat app. |
| Data inputs | Name, email, phone (optional), service of interest, message. |
| Processing logic | Filter: continue only if email exists. Formatter: trim spaces and lowercase the email. CRM: find contact by email, create if not found. Sheet: add a row. Chat: post a notification to the sales channel. |
| Expected outputs | One CRM contact per email, one log row per submission, one notification. |
| Failure points | Form question renamed (blank mapping); CRM connection expired (401); duplicate contacts when the search step is missing; filter fails on “Email ” with a trailing space. |
| Error handling | Autoreplay for temporary errors; an error notification to the owner; a Zap history review for Filtered runs each week. |
| Validation and testing | Submit test entries with a test email, with and without the optional phone, with a trailing space in the email, and twice with the same address. Confirm one contact, two sheet rows, and two notifications. |
| Business application | Leads reach the CRM within seconds and the team is alerted, instead of someone copying form emails by hand. |
Native Zapier steps usually cover this pattern. Custom development becomes worth considering when the CRM needs matching rules beyond a single search, when the form tool has no reliable trigger, or when volume pushes you toward rate limits and task costs that a direct API integration would avoid.
How to confirm the issue is fixed
- Create a new test record in the source app after the fix is published. Old records will not trigger.
- Wait at least one polling interval if the trigger is not instant, then confirm a run appears in Zap history with a Successful status.
- Open the destination record and check every mapped field, not just that the record exists.
- If you replayed failed runs, spot-check the destination for duplicates.
- Re-run App Connections tests and confirm each shows Active.
Common mistakes to avoid
- Turning a Zap back on after an automatic shutdown without reading the errors that caused it.
- Replaying dozens of runs before confirming one replay produces the correct result.
- Editing a Zap’s actions while runs are waiting on a Delay step.
- Reconnecting an app under a different user who does not have the same permissions.
- Renaming form fields, sheet columns, or CRM properties without checking which Zaps depend on them.
- Pushing tests into a live CRM. Use a test contact or a sandbox account and delete test records afterward.
Prevention and monitoring
- Review Zap history weekly with the status filter set to Errored, On hold, and Filtered.
- Enable Autoreplay where your plan supports it, and add error handling or notifications to business-critical Zaps.
- Monitor task usage so a busy month does not reach the pay-per-task maximum unnoticed.
- Where a Zap feeds a CRM, audit a sample of records against the source periodically. If records drift between systems, our guide on CRM data not syncing between applications covers the wider causes.
If you also run workflows in Make, many of the same patterns apply with different terminology; see Make.com scenario not running. For help designing or repairing multi-step Zaps, Modern Streamline offers Make and Zapier automation services.
Still having trouble with your Zap?
Tell Modern Streamline which applications your Zap connects, what data should move between them, and what Zap history shows instead. We can review your requirements and discuss an appropriate solution.
FAQ
Why did my Zap turn off by itself?
Zapier turns off a Zap automatically when it errors on 95% of its runs and has run more than 20 times in the last 7 days. Open Zap history, filter for errored runs before the shutdown, and fix the cause before turning it back on.
Why didn’t my Zap trigger for existing records?
Zaps only trigger for new data created after the Zap is turned on. Polling triggers also skip items whose IDs they have already seen. To move older records, you need a separate method such as Zapier’s Transfer feature or a one-time import.
How long does a polling trigger take?
Zapier’s documented intervals are 15 minutes on Free, 2 minutes on Professional, and 1 minute on Team and Enterprise. Instant triggers run as soon as the app sends the webhook.
Does replaying a Zap run use tasks again?
Yes, successful action steps that run again during a full replay count as tasks. Replaying can also create duplicate records if earlier steps already succeeded, so check the destination first.
What does “On hold” mean in Zap history?
The run is paused rather than failed. Common reasons are a disconnected account, reaching your task limit, a premium feature your plan does not include, or flood protection holding a large batch. Resolve the cause, then replay the held runs.
Sources
- Zapier: Review run statuses in Zap workflows
- Zapier: Zap is not running
- Zapier: How Zap triggers work
- Zapier: How to troubleshoot errors in Zap workflows
- Zapier: View and manage your Zap history
- Zapier: Replay Zap runs
- Zapier: Decide how your Zap handles errors with advanced settings
- Zapier: Zap filters are not working properly
- Zapier: Manage your app connections
- Zapier: Dropdown menu in Zap field is empty or missing items
- Zapier: Common problems with Delay
- Zapier: Zap limits
- Zapier: How pay-per-task billing works
- Zapier: How is task usage measured