Preventing temporary connection initialization errors from disabling production scenarios

Questions
, , ,
1

:bullseye: What is your goal?

I want to make a production-critical Make scenario resilient to temporary third-party connection failures.

Ideally, if a connection such as Google Sheets temporarily returns a 500 error during scenario initialization, I want the scenario to either automatically retry or continue operating without the temporary failure disabling the entire workflow.

:thinking: What is the problem & what have you tried?

This morning, one of my production scenarios failed during initialization because Make was temporarily unable to verify an existing Google connection.

The connection had been working normally for approximately three months. I made no changes to the scenario, Google connection, Google account, or authorization.

Make Support confirmed that the internal_failure represented a temporary 500 error and explained that because it occurred during the initialization phase, the scenario never actually began execution.

As a result:

The scenario automatically stopped/disabled.
Normal error handlers could not run because execution had not started.
All subsequent requests/calls relying on that scenario also resulted in errors while the scenario was stopped.
There was no way inside the scenario to catch or retry the initialization failure.

The issue later resolved by itself. I made no changes and did not reauthorize the Google connection. The same scenario began working again, and I manually clicked Verify on the existing connection afterward and it returned Verified ✓.

I have already contacted Make Support. They confirmed that normal error handling cannot handle this because the failure occurs before execution starts.

I’m trying to determine whether anyone has found a reliable solution within Make for this type of failure.

Specifically:

  1. Is there any Make feature or setting that automatically retries scenarios that fail during initialization?
  2. Is there any way to prevent a temporary initialization error from automatically stopping/disabling the scenario?
  3. Is there another Make-native architecture that people are using for production-critical workflows to protect against this type of failure?
  4. Has Make introduced any newer functionality for recovering from or monitoring AccountValidationError / connection-verification failures?

I am considering moving some of these critical processes outside Make entirely, but I would first like to understand whether there is a reliable solution available within Make.

:clipboard: Error messages or input/output bundles

  1. Module initialization failed with an error:
    Connection couldn’t be verified
    Failed to verify connection ‘My Google connection’. Unexpected error: internal_failure
    Code: AccountValidationError

  2. Scenario initialization failed with an error:
    Connection couldn’t be verified
    Cannot initialize the scenario because of the reason ‘Failed to verify connection ‘My Google connection’. Unexpected error: internal_failure’
    Failed to verify connection ‘My Google connection’. Unexpected error: internal_failure
    Code: AccountValidationError

*Make Support confirmed that internal_failure corresponds to a temporary 500 error and that because the failure happened during initialization, normal scenario error handling cannot be triggered.

:camera_with_flash: Screenshots (scenario flow, module settings, errors)

Screenshot 2026-08-19 133232.png
Screenshot 2026-08-19 133232.png3567×630 192 KB

4

Hello,

Can you check your run history to see if the exponential backoff feature kicked in and resolved this automatically?

I’m 99% sure that it works also for initial phase but your error is not that easy to achieve.

Second option is to use Make.com API- Notifications | Make API | Make Developer Hub

Have a nice day,
Michal

5

My error was specifically an AccountValidationError. Per the documentation you sent me, “if a module in your scenario outputs a ConnectionError or ModuleTimeoutError, Make automatically retries the scenario using exponential backoff.”

However, my error was an AccountValidationError, which is not one of the error types Make lists as being automatically retried.

6

I’m aware of what the documentation says, but Exponential Backoff is one of the latest features – it’s only been available for a few months. AccountValidationError is rare enough that I honestly can’t recall and be 100% sure whether it worked with it.

If I get a few minutes this week, I’ll try to recreate your error using a custom app – that’s the only way to set up a proper testing environment and fail in initial phase.

Have a nice day,
Michal

7

Ohhh okay. I am new to this so maybe I should stop taking things so literally. Thanks for the feedback!

8

Init-time AccountValidationError is the ugly one, because none of the scenario’s error handlers ever run. Make just takes the scenario offline.

Retry/backoff inside the scenario cannot cover a failure that happens before the first module. For production I treat “scenario disabled” as its own watchdog (status via API, re-enable after a health check, page someone).

Do you already have anything watching whether the scenario is still on, or is this the first time it has gone dark from init?

9

This is a real concern for production-critical scenarios. Since the failure happens during initialization, standard error handlers and retries inside the scenario won’t help because execution never actually starts.

One approach I’d consider is adding external monitoring for critical scenarios and using a separate health-check/alert workflow to detect when a scenario becomes disabled. For third-party connections, having a fallback or independent process for critical operations can also reduce the impact of temporary connection-validation failures.

It would be interesting to know if Make plans to introduce automatic retry or recovery specifically for initialization-level AccountValidationError failures.

10

The API workaround is the more concrete fix here. A watchdog scenario running on its own short interval, 5 or 10 minutes, that calls Make’s own API to check whether the target scenario is active, and if it got disabled, calls the same API to re-enable it, closes most of the gap Make Support described. It won’t stop the initial failure but it stops you from staying down until someone notices.

The other angle worth trying is swapping the native Google Sheets/Drive module for an HTTP module using OAuth2 in that specific critical path. Native app connections get verified before the scenario starts running, which is exactly the step that’s failing for you. An HTTP request against the same API happens inside the execution itself, so it’s subject to normal error handling, retry, resume, whatever you’ve set up, instead of blocking the scenario from starting at all. More setup work up front, but it moves the failure point from pre-execution to inside execution, which is the actual problem you’re running into.

Worth checking your scenario’s error handling settings too, specifically how many consecutive errors it takes before Make auto-disables the whole thing. If that threshold is low, a single transient 500 taking the whole scenario down for hours is partly a config issue, not just bad luck.

11

I checked the situation described, and the fact that the issue resolved without any changes is interesting. Since this happened during scenario initialization, I’d be curious whether Make’s exponential backoff actually handled the temporary 500 error before the scenario was disabled.

If the run history shows that the connection error was retried automatically and eventually recovered, that would suggest the backoff mechanism can help with some transient failures. However, if the scenario was already disabled before the retry could occur, then it seems initialization-level AccountValidationError still needs a separate recovery mechanism.

It would be useful to know exactly what the run history shows for the failed initialization and whether any automatic retry attempts were recorded.

12

From what I’ve seen, it depends on where the failure happens. Make’s retry/backoff logic generally kicks in for errors returned by a module during execution, an HTTP timeout or rate limit inside a run, for example. The initialization-level AccountValidationError is different: it happens before the scenario execution starts, during the connection check itself, so it’s not a module retrying inside a run, it’s the platform deciding whether to let the run happen at all. That’s likely why disables triggered by this specific error don’t interact with the execution-level backoff, the scenario is already stopped before backoff would normally apply.

If you check the scenario’s history log for the exact minute it got disabled, you’ll usually see the failed initialization attempt logged with no retry attempts before the disable, that’s the signal it isn’t going through the standard retry path.