Your Automation Stopped Halfway. Resume It or Start Over?

Your automation stopped halfway. Should you resume it or start over?

Resume if the completed steps wrote data somewhere permanent. Restart only if every step so far is safe to repeat. The wrong choice does not just waste a run, it duplicates records, double charges people, or sends the same email twice to somebody who already replied to the first one.

This is the failure mode nobody plans for. People plan for the automation that never runs, because that one is loud. The one that runs three steps out of six and then stops is quiet, and by the time you notice it, the system is in a state that neither your success path nor your error path was designed to handle.

I have been building automations in production for years now, including the Airtable and WhaleSync pipeline behind Ajust, which has delivered more than 25,000 cases. Half finished runs are the thing I now design for first.

What does halfway actually mean in an automation run?

It means some steps committed and some did not. A run is not one action, it is a sequence, and each step that touches an external system leaves a trace behind. Halfway is the state where those traces exist without the rest of the sequence that was supposed to follow them.

Say a run creates a contact in HubSpot, then creates a deal, then posts a Slack notification, then updates a row in Airtable. If it dies after the deal, you have a contact and a deal in your CRM and no record anywhere else that they exist. Nothing is broken enough to alarm anyone. It is just wrong.

The reason this matters is that most automation tools report the run as failed, which sounds like nothing happened. Failed does not mean nothing happened. Failed means the sequence did not finish, and the steps that already finished are still out there.

Why is restarting the dangerous option?

Because restarting replays steps that already succeeded. If the first three steps created records, running the whole sequence again creates them a second time. You have now turned one incomplete run into two incomplete data sets, and the cleanup is harder than the original problem was.

This is the trap I see most often with people newer to automation. Restarting feels clean. It feels like turning something off and on again. But an automation is not a stateless function, it is a sequence of writes into systems that remember what you did.

Restarting is the right answer in exactly one situation: when every step in the sequence is safe to repeat. That is a much rarer property than people assume, and it is worth knowing which of your steps have it before you are staring at a broken run at nine in the evening.

What does replay actually re-run on your platform?

It varies, and the details decide your answer. Zapier's own documentation states that Zapier will replay all steps that stop due to an errored status, and that Filter and Paths steps are never replayed. It also states you must replay steps within 60 days of the initial trigger event.

There is a cost detail worth knowing too. Zapier documents that when you replay an entire Zap, it is considered a new Zap run, and any successful steps will count towards your task usage even if they were already counted in a previous run. So a full replay is not free, in money or in data safety.

Make, n8n and Workato each approach this differently, and the differences are not cosmetic. Read your own platform's documentation on replay and run history before you need it, because the answer changes what your recovery plan should be.

Which steps are safe to repeat and which are not?

A step is safe to repeat when running it twice produces the same end state as running it once. Updating a field to a fixed value is safe. Reading data is safe. Creating a deal in Salesforce is not safe. Sending a Mailchimp campaign is not safe. Charging a card in Stripe is not safe.

The technical name for the safe category is idempotent, and the practical version is simpler: if you ran this step ten times in a row, would anything look wrong afterwards? Setting a status field to "processed" ten times is fine. Appending ten rows to the same Google Sheet is not. Charging a card ten times is a phone call you do not want to make.

Once you sort your steps this way, the resume or restart question mostly answers itself. If everything before the failure point is idempotent, restart. If anything before it is not, resume, or fix the state by hand and then continue from the failure point. Building that safety in deliberately is what idempotency keys are for.

How do you make a run resumable before it breaks?

Give every run an identity and a checkpoint. An identity is a stable reference, usually the ID of the thing being processed. A checkpoint is a field you update as the run advances, so that a later run can look at the record and know exactly how far the previous attempt got.

In practice this is one extra column. I keep a status field on the record being processed, and each step sets it before moving on. When something fails, I do not have to reconstruct what happened from logs and guesswork. The record tells me it reached step four, and I continue from step five.

This costs perhaps twenty minutes to add when you build the automation, and it saves hours the first time something goes wrong. It also makes the run auditable, which matters a great deal when the automation writes to a client's systems rather than your own. The same discipline underpins a usable rollback plan.

What should you do in the first ten minutes after a failure?

Stop the automation before you diagnose it. If the trigger is still live, more runs are queueing up behind the broken one, and every one of them will hit the same wall. Turning it off costs you nothing and buys you the time to think clearly.

Then find out what actually committed. Not what the error message says, what is actually in the systems downstream. Open the CRM, open the sheet, open the table. The error tells you where it stopped, but only the systems themselves tell you what got written before it stopped.

Only after those two things should you decide between resume and restart. I have watched people do this in the opposite order, replaying a run immediately out of reflex, and the replay is what turned a small problem into a data cleanup that took a whole afternoon. What you logged along the way is what makes this ten minutes instead of two hours.

When is doing nothing automatic the right answer?

When the volume is low and the stakes are high. If an automation processes four records a day and each one touches money or a customer relationship, an automatic retry saves you almost no time and exposes you to real risk. A notification and a human decision is the better design.

The Kismet Health work I did runs HubSpot through Zapier, and the thing that makes that kind of setup trustworthy is not clever recovery logic. It is knowing which failures should page a person instead of resolving themselves quietly. Automatic recovery is appropriate for high volume and low consequence, and it inverts badly the other way.

The instinct to automate the recovery too is strong, because it feels incomplete to leave a manual step in. Resist it for the cases where a wrong automatic decision is expensive. A person looking at a half finished run for thirty seconds makes a better call than a retry rule written six months ago.

What should you do next?

Take one automation you already run and sort its steps into safe to repeat and not safe to repeat. That list alone will tell you whether your current recovery habit is resume or restart, and whether it is the right one. Then add a status field so the next failure tells you where it stopped.

Do it on the automation that touches the most important system, not the easiest one. The automations that quietly corrupt data are always the ones nobody thought were risky enough to instrument.

If you have an automation you are not sure how to make recoverable, or you have inherited one and cannot tell what it does when it breaks, reach out. I am happy to look at it with you. Let's chat.