An automation that fails quietly costs more than one that never existed, because you stop checking. A weekly checkup fixes that in about twenty minutes: list the handoffs that touch clients or money, write the output you expect from each, look at the run history for failures and holds, confirm the destination actually received the record, check for duplicates before any retry, and note who fixes what by when.
Editorial research checked September 10, 2026. This is a process guide; Zapier is used as a documented example because its help center describes run statuses, replay and retention in detail. No workflow was executed or replayed for this article, and it contains no affiliate links.
Why weekly, and why a list
A one-person business rarely has more than ten automations that matter: a form that creates a client record, a booking that creates an invoice, a payment that sends a confirmation, a signed contract that starts a project. When one of these stops, nobody on a team notices, because there is no team. The client notices, usually a week later.
The audit checklists written for agencies recommend a review every few months. That cadence is wrong for a solo operator whose flows change whenever a tool updates a field or an authorization expires. A short weekly pass is easier to keep than a long quarterly one, and it catches problems while the run history still exists. Zapier, for example, documents that it “can only guarantee a maximum of 60 days of Zap run data” in its history. Source: Zapier Zap history help, updated June 15, 2026.
If you are deciding which automation tool to use, that is a different question; our Zapier vs Make comparison covers costs and plans. This guide assumes your flows already exist.
Step 1: list the critical flows
Write down every automation that creates, changes or sends something a client or your accountant would miss. Ignore internal conveniences for now. For each flow record four facts: the trigger, the destination, the owner (you, or a tool vendor’s support), and the last time you saw it work. The table below is an illustration, not a template from any product.
| Flow | Trigger | Destination | Expected output |
|---|---|---|---|
| Intake form to client list | New form response | Client database | One new record with name, email and service |
| Paid booking to invoice record | New paid appointment | Accounting tool | One invoice marked paid, matching the appointment date |
| Payment to confirmation email | Successful payment | Email service | One confirmation per payment, none for failed payments |
| Signed contract to project | Document completed | Project tool | One project with the client linked |
Four to eight rows is normal. If you have thirty, most are not critical and can be checked monthly.
Step 2: write the expected output
The column that matters most is the last one. “The Zap ran” is not an outcome; “one invoice exists, marked paid, with the right date” is. Expected output is what you will verify at the destination in Step 4, and it is what tells you whether a duplicate exists in Step 5. Write it as a count and a state: one record, marked paid, linked to the client.
Where possible, add the number you expect per week. If you take about five paid bookings a week, five confirmation emails is right and eleven is a problem even if every run shows success.
Step 3: inspect failures and holds
Open the run history of your automation tool and filter to the last seven days. In Zapier’s Zap history each run carries a status; the documented ones include Successful, Errored, Filtered, Safely halted, On hold, Delayed and Scheduled. The distinctions matter for what you do next:
- Errored means the run “encountered an issue and did not run successfully”; Zapier also documents that a Zap will “automatically turn off if 95% of its runs result in errors in the last 7 days.” A flow that is turned off produces no errors at all, which is why Step 4 exists.
- Safely halted means the run “purposely stopped”, typically because a search step found nothing. It does not turn the Zap off, so it can hide for weeks.
- On hold means the run is paused; documented causes include disconnected accounts, task limits and access policies. Zapier states that when the task limit is reached, actions are held account-wide.
- Filtered means a filter condition was not met and later steps did not run. Correct filtering looks identical to a broken filter in the history.
Sources: Zapier run statuses, Zapier troubleshooting and Zapier reasons a Zap may not run, all updated May 29, 2026. Other tools use different words for the same states; map them once and keep the mapping with your register.
Also check your notification settings. Zapier documents that error notifications go to the account email by default, that the frequency can be set to immediate, hourly summary or never, and that “Zapier will not send any error notification emails when an error handler runs.” A notification you turned down during a noisy week may still be off. Source: Zapier error notifications.
Step 4: confirm the destination
For each critical flow, open the destination and count. If you expected five paid invoices this week, find five. This is the only step that catches the silent failures: a Zap that was turned off, a filter that now excludes everything, a trigger that stopped firing because the source app changed its field names. None of these produce an error in the history.
A practical shortcut is to pick the most recent trigger event you know happened, such as yesterday’s booking, and trace it to its destination record. If that one arrived, check the count; if it did not, you have found this week’s problem.
Step 5: check duplicates before you retry
Retrying is where well-meaning fixes create client-visible mess. Zapier’s replay documentation is explicit: replaying an entire run means “The Zap will replay every single step”, and “Any successful steps will count towards your task usage, even if they were already counted in a previous run.” In other words, a replay re-executes steps that already succeeded. If step one created the invoice and step two failed to send the email, replaying the entire run creates a second invoice. Source: Zapier replay help, updated May 29, 2026.
So before any replay: open the destination, search for the record the failed run should have created, and decide whether you need to replay only the errored step or the whole run. Zapier’s editor offers both “Errored steps” and “Entire Zap” options on paid plans; on the Free plan, manual replay is limited to errored runs. Zapier also documents a time limit: “You must replay steps within 60 days of the initial trigger event.” Source: Zapier, what is replay.
Automatic retries need the same care. Zapier’s Autoreplay “works to retry any failed steps in a Zap run” and is an account-wide setting on Professional plans and higher, with per-Zap overrides on company plans. It is useful for temporary outages and dangerous for flows whose first step is irreversible, such as sending an email or charging a card. Turn it off per flow where a repeat would reach a client. Source: Zapier advanced error settings.
Step 6: resolve connection and field changes
Most recurring failures in Zapier’s documented troubleshooting list are not bugs: missing values in required fields, expired or revoked authentication, insufficient permissions, records that no longer exist, incorrectly formatted data and rate limits. Two of these, expired authorization and renamed fields, appear after you change a password, switch accounts or edit a form. When you find one, fix the cause in the source tool, then re-test the flow with a single new trigger rather than replaying old runs.
Keep the fix small and dated. If a field mapping changed, write which field, which day, and the run you confirmed afterwards. Next week’s checkup starts from that note.
Step 7: record the owner and the next check
End the checkup by writing one line per flow in a log. An illustrative set of fields:
| Field | Example |
|---|---|
| Date checked | 2026-09-08 |
| Flow | Paid booking to invoice record |
| Runs seen / expected | 5 / 5 |
| Failures and holds | 1 on hold, reconnected accounting tool |
| Destination count | 5 invoices, all marked paid |
| Duplicates found | 0 |
| Owner | Me; vendor support if reconnection fails twice |
| Next check | 2026-09-15 |
Escalation examples, again illustrative: a flow that fails two weeks in a row after a reconnection goes to the tool vendor’s support with the run IDs; a flow that produced a duplicate client email gets a written apology and a per-flow switch-off of automatic retries; a flow whose destination count is wrong with no errors gets rebuilt from a single fresh trigger rather than patched.
Export what you need to keep. Zapier documents that history retention is limited and that users who need longer records should export regularly; its default retention is described as 29 to 69 days, with customization only on Enterprise plans. Your log, not the vendor’s history, is your record. Source: Zapier data retention.
A twenty-minute version
- Open the register; confirm no flow was added or changed this week without a row.
- Filter run history to seven days; note errored, held and halted runs per flow.
- For each critical flow, count destination records against the expected number.
- For any gap, search the destination for the missing record before replaying anything.
- Fix causes at the source; re-test with one fresh trigger.
- Write the log line and the next check date.
This routine does not promise a time saving or a reduction in errors; it makes failures visible within a week instead of whenever a client complains. That is the whole benefit, and it is enough.
Frequently asked questions
My automation shows all runs successful. Do I still need to check the destination?
Yes. A turned-off flow, a filter that excludes everything or a trigger that stopped firing produce no runs and no errors. Only the destination count reveals them.
Is it safe to replay a failed run?
Only after checking for the record it should have created. Zapier documents that an entire-run replay re-executes every step, including steps that already succeeded.
How long is run history kept?
Zapier guarantees at most 60 days of Zap run data and describes default retention as 29 to 69 days. Other tools differ; keep your own log.
Should I turn on automatic retries?
For flows whose steps are safe to repeat, such as updating a record, it can help with temporary outages. For flows that send messages or charge money, a repeat reaches the client; Zapier allows per-Zap overrides on company plans, and otherwise the setting is account-wide.
Sources and method
Product statements refer to Zapier’s help-center articles linked beside each claim, checked September 10, 2026, and are used as examples of documented behaviour. The flow register, log fields and escalation examples are editorial illustrations.
Read next
