Fixing connection errors
App modules output the ConnectionError when the app is unavailable. For example, the app might be offline for maintenance.
uses the HTTP 503 and 504 status codes to identify the ConnectionError.
follows the standard error codes and their definitions. Note that it is possible that the third party may not fully comply with the standard.
When a module in your outputs the ConnectionError, you should check the status page of the module app. Chances are that the status page will have the URL https://status.domain, for example https://status.make.com.
When recognizes the module output as the ConnectionError and you don't use any error handling, acts depending on the following attributes:
- scheduling
- enabling of the incomplete executions
| Incomplete executions disabled | Incomplete executions enabled |
|---|---|---|
Scheduled | pauses the scheduling of the scenario for 20 minutes. doesn't rerun the scenario. | pauses the scheduling of the scenario for 20 minutes. retries the incomplete execution with the incomplete execution backoff. |
Instant | reruns the incomplete execution with the backoff. | retries the incomplete execution with the incomplete execution backoff. |
To handle the ConnectionError, you can use the strategies for handling the RateLimitError. The most efficient strategy is to use the Break error handler to rerun the after a delay:
If your triggers with an instant trigger (for example, a custom webhook module), consider enabling sequential processing in scenario settings. With sequential processing, the trigger module processes incoming data one by one in the order they arrive.
Otherwise, skip this step.
If a has incomplete executions and sequential processing enabled, pauses the until the incomplete executions are processed to keep the order of incoming data.
Add the Break error handler to the module that is causing the errors.
Consider setting the delay and the number of attempts according to the importance and the schedule of your .
For example, if the app has occasional downtime for maintenance for a few hours with no availability, it might be best to set a lower number of attempts with longer time periods between them.
On the other hand, if the app is occasionally unavailable because it's overloaded, and the is important for you, it might be best to use a short time period (a few minutes) with a higher number of attempts.
Enable incomplete executions in the settings. will save bundles that caused the error.
For example, if you would use the Webhook trigger to ask questions to ChatGPT, but the ChatGPT app is sometimes overloaded with requests and sending back errors, your Make and Make settings with error handling could look like this:
Whenever the Create a completion module outputs the ConnectionError because the OpenAI servers are overloaded or unavailable, creates an incomplete execution with the Create a completion module.
After the delay set in the Break error handler, reruns the Create a completion module. If the rerun succeeds, will continue scheduling new runs.
If the rerun fails, reruns the module again after the delay, up to the number of attempts set in the Break error handler settings.