How to fix Make's Retry error handler (formerly Break) not triggering

TL;DR: Make's Retry error handler (formerly Break) never fires on HTTP module failures because the module's "Evaluate all states as errors" toggle is off by default; enable it in Advanced settings so 4xx/5xx responses count as errors.

This is a naming trap layered on top of a configuration trap. Make renamed Break to Retry (and Ignore to Skip) in its June 6, 2026 release, so half the guides on the community forum still reference a module that no longer exists under that name - but the trigger condition underneath never changed, and it still catches people building HTTP-based scenarios today.

Why doesn't Make's Retry error handler trigger on HTTP module errors?

The HTTP module's error reporting is opt-in, not automatic. By default, it only reports "related errors" - mapping errors or missing required values - and treats every response status, including a 500 or a 404, as a normal successful bundle. Make's own module documentation states the setting plainly: it lets the module "use the response status to detect errors otherwise, the module reports only related errors (like mapping errors or missing required values)".

With that toggle off, no HTTP status code ever reaches the module's error route - so it doesn't matter which per-module error handler sits there. Retry, Skip, Resume, Commit, and Rollback are all equally blind to the failure, because Make never classifies the response as an error in the first place. A user hit this exact symptom on the Make community forum: a Break (now Retry) handler wired to retry a failing HTTP call never triggered, no matter how the filter in front of it was configured, even with the filter left empty. Another user identified the cause: enabling "Evaluate all states as errors" in the HTTP module's advanced settings made the handler catch the failure immediately.

How do you fix the Retry handler not triggering?

1. Open the HTTP module's advanced settings. Double-click the module, then switch on the advanced settings toggle at the bottom of the panel.
2. Turn on "Evaluate all states as errors." With it enabled, every response status except 2xx and 3xx counts as an error the scenario can act on; with it disabled, the module never reports a status-code failure at all.
3. Confirm the Retry handler is attached to that module's error route. Right-click the HTTP module, choose Add error handler, then Retry if it isn't already there.
4. Set the retry attempts and delay. The handler defaults to 3 attempts with a 15-minute delay between them; adjust both in the handler's own settings if the failing endpoint needs a faster or slower cadence.

How do you verify the fix worked?

Point the HTTP module at an endpoint that reliably returns a 4xx or 5xx status, run the scenario once, then open Scenario detail -> History and expand that run. Before the fix, the run shows a plain successful bundle with the error body embedded in the output. After the fix, the module shows a red error badge, the run appears as an incomplete execution, and the Retry handler's scheduled retry time is visible on the execution detail. If the retry count and delay match what you set in step 4, the handler is working correctly.

What if the Retry handler still won't fire?

Three things beyond the toggle commonly block it. A filter placed between the module and the handler can silently drop the bundle before it reaches the error route - remove the filter temporarily to test. If the scenario has multiple HTTP modules, the handler may be attached to the wrong one; check the small red icon on the module itself, not just the route. And if incomplete executions are disabled in scenario settings, the handler stores the failure but never resumes it automatically, which looks identical to "not triggering" from the outside. For the broader case where the entire scenario doesn't run at all, work through the Make scenario won't trigger checklist first; this fix only applies once the scenario is running and a specific module is failing. If you're chasing a different HTTP module quirk, the Make HTTP module 40-second timeout lives in the same Advanced settings panel but is a separate cap on request duration, not error reporting. For a running catalog of Make error strings and their fixes, the Automation Error Index indexes this one alongside the other per-module error handlers.

FAQ

Is Break the same thing as Retry in Make?

Yes. Make renamed the Break error handler to Retry, and Ignore to Skip, in its June 6, 2026 release. The behavior is unchanged - only the label in the module picker and the scenario editor is different.

What does "Evaluate all states as errors" actually change in the HTTP module?

With it off, the module reports only request-level errors like mapping problems or missing required values, never a status code. With it on, every response status other than 2xx and 3xx is treated as an error the scenario can catch.

How many times does Make's Retry handler retry by default?

Three attempts with a 15-minute delay between each, and both values are editable in the handler's own settings. That's separate from Make's automatic system-level retry schedule for connection and rate-limit errors, which escalates on its own timetable and doesn't involve a Retry handler at all.

Does enabling "Evaluate all states as errors" break 3xx redirects?

No. The setting only reclassifies statuses outside the 2xx and 3xx ranges as errors, so redirect responses still pass through as successful bundles.

Why doesn't my Retry handler's schedule match what I configured?

Check whether Make's automatic retry for connection or rate-limit errors is also active on the same module - that schedule runs independently of the handler's own attempt count and delay, and the two can appear to conflict when they're really two separate retry mechanisms stacking on the same failure.