Your Zap Broke Overnight: How Do You Find Out Why?

A Zap failed overnight, so where do I actually start?

Start in Zap history, not in the Zap editor. History tells you what happened to real data. The editor only tells you what happens when you press Test, which is a different question with a different answer. Open the failed run, read the steps in order, and resist the urge to change anything for the first five minutes.

The reason that order matters is that editing a Zap changes the thing you are trying to diagnose. I have watched people open the editor, retest a step, get a green tick, and conclude the problem fixed itself. It did not. The test ran with different data than the failure did.

So the first move is always read-only. You are collecting evidence about one specific run with one specific payload, and that evidence disappears the moment you start editing around it.

What is Zap history actually telling you?

Each run gets a status, and the status is a claim about the whole run rather than about your data. A run can finish successfully and still put garbage in your CRM. That gap between technically succeeded and actually correct is where most of the painful automation bugs live, and no dashboard will flag it for you.

Read the run top to bottom and note two things per step: did it execute, and what did it receive. The second one is the useful one. The moment you can name is the moment a field arrived empty, arrived as text where you expected a number, or arrived carrying a value from the wrong record entirely.

Narrow the history before you read it. On a Zap that fires hundreds of times a day, scanning everything chronologically wastes an afternoon. Work from the errored runs, find the earliest failure rather than the most recent one, and move forward from there. The earliest failure happened while the cause was still fresh.

Why is the errored step rarely the broken step?

Because automations fail downstream of their causes. A step that writes to HubSpot throws the error, but the reason is that a step three positions earlier produced a blank email address. Zapier is honest about where execution stopped. It cannot tell you where the logic went wrong.

My working taxonomy has five buckets, and I check them in this order. Trigger fired on the wrong thing. Authentication expired. The incoming data changed shape. A downstream app rejected valid data. Or everything succeeded and the output is still wrong. Roughly speaking the first four announce themselves and the fifth one does not, which is why the fifth one costs the most money.

The one that catches people out is the third. Nobody tells you when a form gets a new field, a spreadsheet column gets renamed, or an API starts returning null where it used to return an empty string. Your Zap did not break. The world around it moved, and it is the single most common cause I see in client automations.

What does replay actually re-run?

This is the question worth getting right before you click anything, because replay is not one behaviour. Zapier's own documentation is explicit that when you replay all steps, the Zap will replay every single step in the Zap, including the trigger and all previous steps. There is also a separate option for replaying only the errored steps.

Those two choices have very different consequences. Replaying only the errored steps picks up where the run stopped. Replaying all steps re-executes work that already completed, which on a Zap that sends email or creates records means doing it twice.

So before you replay anything, ask one question: is every step in this Zap safe to run again? If the Zap creates a record, sends a notification, or charges something, the answer is no and you want the errored-steps option. If the Zap only updates a field to a fixed value, replaying the whole thing is harmless.

Zapier also notes that on the Free plan, manual replay is only available for Zap runs with an errored status. If you are on Free and staring at a run that is on hold rather than errored, that is why the replay option looks unavailable.

When should you let autoreplay handle it?

Autoreplay is the feature that stops you waking up to a queue of failures. Zapier describes it plainly: when you enable autoreplay, Zapier will automatically replay any Zap run with an errored status. Which plans include it is the kind of detail Zapier revises, so check its own help docs before you build a process around it.

Turn it on for failures that are genuinely transient. An API that returned a timeout at three in the morning will probably succeed at three fifteen, and having a human involved in that retry is pure waste.

Leave it off, or at least be careful, where a retry could duplicate something a customer sees. Automatic retries and non-idempotent actions are a bad combination, and the failure mode is embarrassing rather than merely annoying. Two welcome emails is worse than one late welcome email.

The honest general principle is that automatic retry is a good answer to infrastructure flakiness and a bad answer to a logic bug. If the same run fails on every retry, autoreplay is just generating noise on your behalf.

How do you tell a temporary failure from a real one?

Look at the shape of the failures rather than the text of any single error. One failure in a thousand runs, clustered in time, is infrastructure. A hundred failures spread evenly across a week is your logic. The distribution tells you more than the message does.

Then check whether the failures share a payload characteristic. If every failed run involves a record with no company name, or a submission from a particular form, or a contact created by a particular integration, you have found the real bug and the error message was a symptom.

I do this with an export rather than in the interface. Pull the failed runs out, put the timestamps in one column and the distinguishing field in another, and the pattern shows up in about a minute. It is unglamorous and it beats staring at a list.

What if the Zap ran fine and the data is still wrong?

This is the expensive one, and it needs a different method entirely. A run that reports success has no error to read, so history will not help you. You find these by checking the destination rather than the automation, which almost nobody does on a schedule.

The pattern that produces them is usually a mapping mistake that is valid but wrong. A field pointed at the right kind of value from the wrong step. A lookup that returns the first match rather than the correct match. A date written in the wrong timezone. Every one of those passes every check Zapier can perform, because the data is well formed.

Across the automations I keep in production, including the HubSpot work running through Zapier for Kismet Health and the Airtable side of Ajust running through WhaleSync, the checks I trust least are the ones that only watch for errors. An error is a gift. A quiet wrong answer is the thing that reaches a customer. That is the whole argument I made for monitoring silent automation failures rather than only alerting on red.

How do you stop debugging the same Zap every month?

By changing something structural after the second identical failure, not the fifth. One failure is an incident. Two of the same failure is a design problem, and patching it a third time is a decision to keep paying that tax forever.

The cheapest structural fixes are usually these. Add a filter step so the Zap refuses to run on data it cannot handle, which converts a mysterious error into a clean skip. Default the fields that keep arriving empty. Split one long Zap into two shorter ones so a failure halfway through does not strand the whole job.

Write down what the Zap is for and what it does when it fails, and keep that next to the Zap rather than in your head. Every time I have skipped this on my own work I have paid for it, which is why I now treat writing the runbook before shipping as part of building the automation rather than paperwork after it.

And sometimes the right answer is that the workflow has outgrown the tool. When a Zap needs five filters, three formatter steps and a lookup table to stay upright, you are writing a program inside a product that is not a programming environment. I have written separately about when to move an automation out of Zapier and into code, and the signal is almost always complexity rather than volume.

What should you do next?

Next time a Zap breaks, run it in this order. Open history, find the earliest failure, read what each step received, classify the failure into one of the five buckets, decide whether replay is safe, then replay the narrowest thing that fixes it. Only after that do you open the editor.

Then do the part everyone skips. Ask whether this failure can happen again, and if the answer is yes, spend twenty minutes making it impossible rather than making it fixed. That twenty minutes is the difference between an automation you own and one that owns you.

If you have an automation that keeps breaking and you are tired of being its on-call engineer, get in touch. I am happy to look at the run history with you and tell you honestly whether it needs a patch or a rebuild.