Make.com error handlers for developers: Skip, Retry, Resume, Rollback, Commit

If you come from code, Make.com error handling is easiest to understand as a catch block attached to a single module. When that module throws, Make follows the error handler route you attached to it, and the error handler at the end of the route decides what happens to the run.

Two of those handlers were renamed in May 2026: Ignore is now Skip, and Break is now Retry. Behaviour didn't change. Older tutorials, forum answers and exported blueprints (builtin:Ignore, builtin:Break) still use the old names.

The default: no handler at all

Without a handler, what happens depends on the Store incomplete executions scenario setting:

• Off: Make applies Rollback. The run stops with an error status. After 3 errors in a row (the default for Errors before deactivation), a scheduled scenario is switched off. A scenario with an instant trigger (e.g. a webhook) is switched off after the first error.
• On: Make stores the failed run as an incomplete execution and the run ends with a warning instead.

So "no handler" isn't neutral. With storing off, it's the most disruptive option.

The five handlers as code

A rough mapping (pseudo-code, not literal Make syntax):

try {
  result = module(bundle)
} catch (err) {
  // Skip (formerly Ignore)
  return                         // drop this bundle, continue with the next; run = success

  // Resume
  result = fallbackValues        // continue as if the module returned these; run = success

  // Retry (formerly Break)
  storeIncomplete(bundle)        // park it; optional auto-retry: N attempts at an interval; run = warning

  // Rollback
  revertTransactional(); fail()  // stop, undo transactional modules only; run = error

  // Commit
  commitTransactional(); stop()  // stop, keep transactional changes; run = warning
}

The details that matter in practice:

• Skip drops the failed bundle and the run still ends as a success. Nothing is stored. Without logging, the failure is invisible.
• Resume substitutes output values you define. Good for optional data (e.g. a missing enrichment field), dangerous for important data, because placeholders flow into later modules.
• Retry needs Store incomplete executions turned on; Make flags the handler until you do. With Automatically complete execution set to Yes, you choose the number of attempts and the interval. With No, the item waits in the Incomplete executions tab for you.
• Rollback and Commit only affect transactional modules (marked with an ACID tag, such as Data store or MySQL). A row already added to Google Sheets, an email already sent, or an HTTP call already made is not undone.
• An error route that ends without a handler behaves like Skip, as long as nothing on the route fails. A route with only a Slack alert is a valid pattern.

One more thing worth knowing: with incomplete executions enabled, Make already retries ConnectionError and RateLimitError automatically, so you don't need a Retry handler just for those.

A practical HTTP example

A typical setup for an API call:

1. On the HTTP module, set "Evaluate all states as errors (except for 2xx and 3xx)" to Yes. That's the label in the HTTP (legacy) module docs; the newer HTTP app may word it differently. Without it, a 4xx/5xx response counts as a success and no handler runs.
2. Right-click the module → Add error handler.
3. Use filters on the error routes to separate cases:
   • Rate limit / server error (status 429 or 5xx) → Retry, e.g. 3 attempts, 10 minutes apart.
   • Client error (other 4xx) → log the details → Skip.
4. The log step is a Google Sheets → Add a Row with a timestamp, the module name and the error message. For the timestamp:

{{now}}

Check the error output of a failed Run once for the exact field names to filter on. Retrying a 400 Bad Request just repeats the same failure. Retrying a 429 often succeeds later.

A useful log row has five columns: time, scenario name, failing module, error message, and an identifier for the item (an email, an order ID, a row number). The identifier is what lets you fix the data by hand later. Without it, the log tells you that something failed but not what.

Choosing quickly

Is the failure likely temporary (429, 5xx, timeout)?        → Retry
Is the data optional and a default is safe?                  → Resume (with a realistic value)
Is the item worthless if it fails (e.g. a test ping)?        → log → Skip
Do you use data stores and need all-or-nothing?              → Rollback / Commit
Is it a scenario you check daily and rarely fails?           → at minimum, an alert route

Not every module needs a handler. Start with the modules that talk to external systems (HTTP, CRMs, email, payment tools). That's where failures come from that your scenario doesn't control. Internal steps like Set variable or a text formula rarely fail for reasons a handler could fix. If they fail, the mapping is wrong, and that's a bug to fix rather than handle.

Each handler belongs to one module. If three modules call the same API, each gets its own error route. It's tedious, but it keeps the behaviour explicit.

Settings that change handler behaviour

Store incomplete executions   → required for Retry; storage counts toward your plan
Process data in order         → new runs wait until incomplete executions are resolved
Errors before deactivation    → errors in a row before a scheduled scenario is switched off (default 3)

Also note: Make doesn't store an incomplete execution when the error happens in the first module, unless that module has a Retry handler.

Common mistakes

• Retry with "Store incomplete executions" off: there's nowhere for the bundle to go.
• Skip without a log step: silent data loss.
• Resume with "TBD" placeholders: they end up in your CRM.
• Expecting Rollback to delete a Sheets row or unsend an email: it can't.
• Retry creating duplicates: if the module partly succeeded (the record was created, but the response timed out), a retry can create it again. Use idempotency keys or a search-before-create step.

Testing

Break things on purpose. Point a module at an invalid credential or a URL that returns 500, run the scenario, and check that the handler does what you expect: a stored incomplete execution, a log row, or an alert. Make's docs say an error handler doesn't consume operations when it activates, but ordinary modules on the error route (like the logging row) use credits as usual.

The full guide covers each handler step by step, with a common-errors list and FAQ: Make.com error handling explained.

Want a small, safe scenario to practise on? My free quote follow-up template (Google Sheets → Gmail draft → Sheets update) never sends email, so you can add an error handler route to its Gmail module and break things freely: free quote follow-up template.