How to design error routes in a Make scenario

How should you design error routes in a Make scenario?

Decide, for each module that can fail, what the business needs to happen next: skip the record, retry later, use a fallback value, keep what already ran, or undo it. Then attach the matching error handler on an error route, and send a notification from that route so a person knows. Do not leave it to the default.

Make scenarios usually fail at the edges. An API times out, a record is missing a field, a rate limit kicks in, or a third-party app changes its response. The scenario itself is fine. The question is what happens to the one bundle that hit the problem, and to everything after it.

This article walks through Make's current error handlers, what each one is for, and how I would choose between them for common revenue and content automations. The handler names have changed over time, so it is worth checking against Make's live help center rather than memory.

What happens when a Make module fails with no error route?

Make's help center states that Rollback is the default error handling if you do not set any error handling and keep incomplete executions disabled. It also says that when a scenario finishes with an error a specified number of times in a row, Make disables the scenario. So an unhandled error can quietly switch off an important automation.

That second point is the one that bites. A lead routing scenario that hits a few bad records in a row can end up disabled, and new leads stop flowing until someone notices. Nobody notices quickly, because a disabled scenario produces no output to look at.

Make also notes that if you enable incomplete executions, all scenario errors turn into warnings. That changes the picture, because failed runs are stored instead of simply ending. Know which setting your scenario uses before you design anything else.

What error handlers does Make offer today?

Make's help center currently lists five handlers. Skip disregards errors and lets the scenario process subsequent bundles. Retry stores incomplete executions and enables automatic or manual retries. Resume sets a substitute value for a failed module and continues. Commit stops the scenario and saves processed changes. Rollback stops the scenario and reverts changes.

If you learned Make a while ago, some of these names may be new to you. Older guides and community threads refer to handlers by earlier names. Go by the current help center when you build, because the labels in the editor follow it.

On the editor canvas, Make says an error handling route is visually identified by a transparent, dotted connection. That makes error routes easy to spot when you review a scenario someone else built.

When should you use Skip?

Use Skip when one bad record should not hold up the rest, and losing that record is acceptable. Enriching a long list of companies is a good example. If one company lookup fails, you want the other records to keep moving. Pair Skip with a notification or a log, so skipped records do not disappear silently.

The danger with Skip is that it is comfortable. Scenarios stop failing, and that feels like success. But every skipped bundle is work that did not happen. If you skip leads, invoices, or form submissions, you are choosing to lose them.

My rule is that Skip is fine for nice-to-have enrichment and wrong for anything that touches money, customers, or legal records. For those, use Retry or stop the run.

When should you use Retry?

Use Retry for temporary problems that will likely fix themselves, such as timeouts, rate limits, or a third-party service that is briefly down. Make describes Retry as storing incomplete executions and enabling automatic or manual retries. The failed work waits safely instead of vanishing, and someone can rerun it after the cause is fixed.

Retry is my default for anything important. A lead that fails to reach the CRM should not be skipped. It should wait in a queue until the CRM accepts it, and someone should be told it is waiting.

Retries need a safety check, though. If a retried step creates a record, running it twice could create a duplicate. I covered how to make steps safe to repeat in what to do when an automation runs twice.

When do Resume, Commit, and Rollback make sense?

Resume fits when a sensible fallback exists, like a default owner when a lookup fails. Commit fits when steps already completed should stay saved even though the run stops. Rollback fits when partial work is worse than none, and you would rather undo everything than leave records half updated. Each answers a different business question.

Resume is easy to overuse. A fallback value keeps the scenario moving, but it can hide a real problem. If half your leads land on the default owner because the lookup keeps failing, the fallback has become the system. Log every time Resume fires.

Commit and Rollback are about consistency. Think through what a half-finished run leaves behind. If an order was created but the invoice step failed, is that better or worse than nothing? The answer tells you which one to use.

How should you get alerted when an error route fires?

Add a notification step on the error route itself, before the handler, so every handled error tells someone. Send it where the owner already works, such as Slack or email, and include the scenario name, the failed module, the error message, and a link to the run. An error handled silently is still an error you need to know about.

Make notes that when an error handler activates, it does not consume operations, and Make does not bill you for handling unexpected events. That makes it easier to justify putting error routes on every risky module rather than only the obvious ones.

Decide who receives the alert, too. A message to a shared channel that nobody owns is easy to ignore. I wrote about assigning that responsibility in who gets the alert when an automation fails overnight.

How do you test error routes before going live?

Force each error on purpose. Send a record with a missing required field, point a module at a test endpoint that returns an error, or temporarily use bad credentials in a copy of the scenario. Then confirm the right handler fires, the alert arrives, and the data ends up where you expect.

Test in a copy of the scenario, not the live one. Error testing involves breaking things on purpose, and you do not want test failures reaching real customers or real CRM records.

Write down what each error route is meant to do. When the scenario changes months later, that note tells the next person why a module retries instead of skipping. The decision behind each choice is harder to rediscover than the setting itself, which I discussed in whether an automation should retry or stop and ask.

What should you do next?

Open your most important Make scenario and list every module that calls an outside service. For each one, decide whether a failure should skip, retry, resume with a fallback, commit, or roll back. Add the matching handler on an error route, put an alert before it, and test each route on a copy before relying on it.

Start with the scenario that would hurt most if it were disabled for a day. That is usually lead routing or anything that touches billing.

If you want help reviewing your Make scenarios and adding error handling that holds up, reach out. I build and maintain automations for B2B teams, and I am happy to look at yours and point out where it could fail quietly.