Free tools Windows power users keep installed
One-click scans. No signup required.
To handle errors in a Make.com webhook scenario, first enable Store incomplete executions, then inspect which module failed and choose a recovery that fits the error: retry temporary failures, correct bad data or configuration, or use an error handler such as Skip, Resume, Commit, or Rollback when its consequences are acceptable. A webhook may start the scenario; a later module can be the actual source of the error.
How do I handle webhook errors in Make.com?
- Open the scenario settings and turn on Store incomplete executions. Make says incomplete execution storage is off by default. Saved runs can then be reviewed in the scenario’s Incomplete executions tab. A Retry error handler also requires this setting. Make’s overview of error handling
- Open the failed execution and identify the module that raised the error. Do not assume the incoming webhook itself failed: the trigger may have succeeded before a downstream module encountered a problem.
- Classify the error. For a transient connection, rate-limit, or module-timeout error, use Make’s documented retry behavior or a configured Retry handler. For invalid data or a runtime/configuration problem, correct the cause before trying again.
- Choose a handler only after checking what it will do to the bundle and any changes already made. Skip discards the affected bundle; Resume inserts a substitute value; Commit saves processed changes and stops; Rollback reverts processed changes and stops.
- Review the stored execution and retry or manually resolve it when appropriate. Retrying from the failed module can be useful after a temporary problem or after you have corrected the cause.
Which errors can Make retry automatically?
Make documents automatic retries for RateLimitError, ConnectionError, and ModuleTimeoutError when the incomplete-execution conditions apply. The documented schedule uses exponential backoff. Make lists intervals of 1, 10, 10, 30, 30, 30 minutes, followed by 3 hours and 3 hours for the covered error categories. These are the intervals in Make’s current help-page description, not a guarantee that every webhook or every scenario error will be retried. Automatic retry of incomplete executions
![Computer Networking Bible: [3 in 1] The Complete Crash Course to Effectively Design, Implement and Manage Networks. Including Sections on Security, Performance and Scalability](https://m.media-amazon.com/images/I/41H4YJnxKgL._SL160_.jpg)
As an Amazon Associate I earn from qualifying purchases.
Automatic retries stop when an execution resolves. If all attempts fail, the execution becomes Unresolved; you can retry it or resolve it manually. Make’s documentation also says Retry-handler defaults can be customized. The help page lists three attempts and a 15-minute delay as the handler defaults, so check the settings for your scenario rather than assuming they have not been changed.
Recommended Free Tools
When should you use a Retry error handler?
Add a Retry handler to the module that may fail when you want to manage a retry route for an error. It stores the error details and the remaining flow as an incomplete execution. Depending on how you configure it, the execution can be completed automatically or left for manual action. Enable Store incomplete executions before relying on this handler. Make’s Retry error handler guide
#1 Best Overall
Retry is most suitable when a later attempt may succeed—for example, a temporary connection issue or a rate limit. It is usually a poor first response to a deterministic problem such as a required field being absent or a mapping being invalid: rerunning unchanged data or configuration can reproduce the same failure. Make’s guidance distinguishes transient errors from errors such as RuntimeError and DataError, which often need manual correction. Make’s automatic retry guidance and incomplete execution management
What does each Make error handler do?
| Option | Effect | Use when | Main caution |
|---|---|---|---|
| Store incomplete executions, then inspect | Saves an unfinished run for investigation and possible retry or manual resolution. | The cause is unknown, intermittent, or needs a person to act. | Stored executions use an organization allowance and storage can fill. |
| Retry | Stores error context and the remaining flow for an automatic or manual retry. | A later attempt may succeed, or you have corrected the cause. | An unchanged data or configuration error may fail again. |
| Skip | Discards the affected bundle and continues the flow. | The invalid bundle is harmless to the intended business outcome. | The run can be marked successful even though that bundle was omitted. |
| Resume | Provides a configured substitute value for the failed module and continues. | You have a valid, deliberate fallback value. | A fabricated or unsuitable substitute can lead to incorrect downstream decisions. |
| Commit | Saves processed changes and stops the scenario. | Completed changes should remain saved even though the scenario stops. | Consider whether partial completion leaves connected systems consistent. |
| Rollback | Stops the scenario and reverts processed changes. | Changes made during the run should be undone after failure. | Confirm that rollback behavior fits the connected systems and their side effects. |
These handlers do not all mean “try again.” Skip omits data, Resume substitutes data, and Commit or Rollback changes what happens to work already processed. Make’s error handler documentation describes these outcomes; choose based on the scenario’s data requirements and side effects.
What happens when incomplete-execution storage is full?
Enabling storage does not mean executions are kept indefinitely. Make’s Enable data loss setting controls what happens when the incomplete-execution storage allowance is full: with data loss disabled, the scenario is disabled; with it enabled, the scenario continues, but executions that do not fit are discarded. The choice is a trade-off between stopping the scenario and potentially losing failed work. Make’s overview of error handling
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Before enabling data loss, decide whether uninterrupted processing is more important than preserving each failed execution for review. If the failed work must not be omitted, do not treat continued execution as successful recovery.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Can Make guarantee that a webhook sender will redeliver a failed request?
The Make help pages cited here explain scenario-level incomplete executions and error handling; they do not establish a universal webhook-sender retry policy, a specific HTTP response for every failure, or guaranteed redelivery of the original payload. Do not assume that fixing a downstream module will cause the sender to transmit the webhook again. Use the stored execution and Make’s retry or resolution options for the scenario run, and consult the sender’s own documentation for its delivery behavior.
Quick Recap
Best Value
- Used Book in Good Condition
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.
