iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To handle errors in a Make.com webhook-triggered scenario, first enable Store incomplete executions, then inspect the failed module and choose a recovery action that matches the cause. Make documents automatic retries for rate-limit, connection, and module-timeout errors; invalid data or runtime problems often need correction before another attempt. A webhook is only the trigger—an error may come from a later module.
How do I handle webhook errors in Make.com?
- Preserve failed runs. Open the scenario settings and enable Store incomplete executions. Make says this is off by default. Stored runs appear in the scenario’s Incomplete executions tab, where you can inspect, retry, or manually resolve them. The setting is also required for a Retry error handler. See Make’s overview of error handling.
- Find where the failure occurred. Open the execution details and identify the module that failed. The webhook may have started the scenario successfully while a later app or data-processing module caused the error.
- Classify the cause. A temporary connection, rate-limit, or timeout problem may succeed on another attempt. A malformed value, mapping problem, or runtime error usually needs a change to the data or scenario configuration first.
- Choose a recovery action. Retry when another attempt could work; correct the cause and resolve the run when it cannot. Use Skip, Resume, Commit, or Rollback only when their effects on data and completed work are acceptable.
- Check the outcome. Confirm the execution is resolved and verify the downstream result in the connected service. Do not assume a successful scenario status means every bundle was processed.
These controls govern Make’s scenario execution. The cited Make documentation does not establish whether a webhook sender retries delivery, what HTTP response Make returns in every case, or whether an incoming payload will be redelivered.
Which errors can Make retry automatically?
Make documents automatic retries for RateLimitError, ConnectionError, and ModuleTimeoutError when incomplete-execution conditions apply. These categories can represent temporary conditions, so a later attempt may work. This is not a promise that every webhook-related error is retried.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchMake’s current help-page schedule for the listed error categories is 1, 10, 10, 30, 30, and 30 minutes, followed by two 3-hour intervals. Treat these as the documented schedule, not a guarantee for every scenario or future product configuration. See Automatic retry of incomplete executions.
#1 Best Overall
By contrast, a deterministic data or configuration problem is likely to recur if nothing changes. Make’s guidance identifies runtime and data errors as cases that often require manual changes. Fix the offending value, mapping, or configuration before retrying; otherwise, another attempt may simply reproduce the same failure. See Manage incomplete executions.
What does each Make error handler do?
Handlers are not interchangeable: they determine whether Make discards a bundle, substitutes a value, retries, or stops with changes saved or reverted. The choice should reflect what the scenario is allowed to omit or change.
Rank #2
| Option | Effect | Use when | Main caution |
|---|---|---|---|
| Store incomplete executions, then inspect | Saves an unfinished run for investigation or later action. | The cause is unknown, intermittent, or needs a person to fix it. | Storage has an organization allowance and can fill. |
| Retry | Stores the error context and remaining flow, then retries automatically or leaves the execution for manual action, depending on configuration. | A temporary failure may clear on another attempt. | A deterministic data or configuration error can fail again unchanged. |
| Skip | Discards the affected bundle and continues the flow. | The invalid bundle is genuinely safe to omit. | The run can be marked successful even though that bundle was omitted. |
| Resume | Supplies a configured substitute value and continues. | A valid fallback is defined for the failed module’s output. | An invented or unsuitable substitute can lead to incorrect downstream decisions. |
| Commit | Stops the flow and saves changes already processed. | Keeping completed changes is preferable to undoing them. | Consider partial completion and consistency across connected systems. |
| Rollback | Stops the flow and reverts processed changes. | Undoing completed work is the appropriate failure response. | Confirm rollback is suitable for the connected systems and their side effects. |
Make explains handler behavior in its Error handlers documentation. In particular, Skip is not a repair: it removes the bundle from the flow. Resume is not a retry: it continues using the substitute you configure.
When should you use a Retry error handler?
Add a Retry handler to a module when you want to manage a retry route for that module’s failure. It stores error details and the remaining flow as an incomplete execution; you can configure automatic completion or leave the item for manual action. Enable Store incomplete executions first.
Make’s documented Retry-handler defaults are three attempts with a 15-minute delay, and the defaults can be customized. Those values are defaults, not a requirement for every scenario. A Retry handler is most useful when a repeat attempt is plausible; it does not correct invalid data or a broken mapping. See Retry error handler.
How do you retry or resolve a stored execution?
Automatic retries rerun from the module that caused the error. When an execution resolves, retries stop. If the attempts fail, the execution becomes unresolved and can be retried or manually resolved from the Incomplete executions tab.
- For a temporary connection, rate-limit, or timeout error, allow the documented retry behavior or retry the stored execution after the condition clears.
- For a data or runtime error, correct the input, mapping, or configuration before retrying or manually resolving the execution.
- For a deliberately skipped bundle or resumed execution, check that the resulting business record is acceptable; a completed run alone does not prove that the original data was handled as intended.
Make describes cases that do not create incomplete executions in Errors that don’t create incomplete executions. Consequently, incomplete-execution storage is a recovery mechanism for eligible failed runs, not a record of every possible error.
Recommended Free Tools
What happens if incomplete-execution storage is full?
Make provides an organization storage allowance, and incomplete executions can use it up. When storage is full, the scenario’s Enable data loss setting determines the tradeoff: with data loss disabled, the scenario is disabled; with it enabled, the scenario continues and executions that do not fit are discarded. See Make’s overview of error handling.
Do not enable data loss merely to keep a scenario running if losing failed work is unacceptable. Review stored executions and the organization’s available storage, then decide whether to free capacity or accept that excess executions may be discarded.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
