Make AccountValidationError at init: the watchdog fix
An init-time AccountValidationError disables a Make scenario before any module runs, so error handlers and exponential backoff never fire. Build a watchdog scenario that polls the Make API and re-enables it.
TL;DR: An init-time AccountValidationError disables a Make scenario before any module runs, so no error handler fires; the fix is a watchdog scenario that calls POST /scenarios/{id}/start when the Make API shows the scenario off.
The failure looks like this: a scheduled production scenario stops overnight, and the history log shows "Scenario initialization failed ... Failed to verify connection 'My Google connection'. Unexpected error: internal_failure. Code: AccountValidationError". Make could not verify an existing connection before the run started, and instead of retrying, it took the whole scenario offline. The Make community thread that documents this pattern is one entry in our Automation Error Index of platform-specific errors and fixes.
What does the init-time AccountValidationError actually mean?
Before a scenario runs, Make verifies every connection used by its native app modules. That verification happens outside the scenario's execution. When Google's side returned a temporary internal_failure (a 500-class error), Make treated it as an account validation failure and refused to start the scenario. In the documented case, the connection had worked for about three months with no changes, Make Support confirmed the error was temporary, and a manual "Verify" on the connection later passed. The scenario was never broken - Make just disabled it during a bad moment.
Two error strings show up together in the history log: "Module initialization failed with an error: Connection couldn't be verified" and "Scenario initialization failed". Both carry Code: AccountValidationError, and the second one is the important one: initialization failed, so the scenario never began execution.
Why don't error handlers and exponential backoff fire?
Error handlers attach to modules inside a running execution. An init-time failure happens before the first module, so there is no execution to attach to - the handlers, the Retry route (renamed from Break in Make's June 6, 2026 release - see our guide to the Retry error handler), and rollback routes all stay silent. Make auto-stops the scenario and moves on.
Make's exponential backoff documentation is explicit about what gets retried automatically: "When a module in your scenario outputs a ConnectionError, or ModuleTimeoutError, Make automatically retries the scenario using exponential backoff." AccountValidationError appears nowhere in that list. The rerun schedule (1m, 10m, 10m, 30m, 30m, 30m, 3h, 3h with incomplete executions enabled, or 1m, 2m, 5m, 10m, 1h, 3h, 12h, 24h without it) never engages, because backoff reruns are a scenario-level retry of a failed execution - and there was no execution. Make Support also confirmed the community OP's reading: backoff does not cover this error.
The history log gives you a diagnostic fingerprint: the failed init attempt shows no retry attempts before the disable. A normal module failure with backoff enabled would show rerun entries. Zero retries plus an instant disable means the failure bypassed the standard retry path entirely. Make also disables scheduled scenarios after three consecutive errors, so a repeated init failure shortens that timeline to almost nothing.
How to recover a scenario Make already disabled?
The transient failure usually resolves on its own - in the documented case it did, with no changes on the user's side. Recovery is manual unless you automate it: confirm the connection verifies again (Connections page, run "Verify"), then flip the scenario back on with the Scheduling toggle. The problem is the gap: a production scenario can sit disabled for hours, and Make's one email is easy to miss.
How to build the watchdog that re-enables it automatically?
Community member Aneeq_Iftikhar's recipe - endorsed in the thread - is a separate watchdog scenario on a 5-10 minute schedule that checks the target scenario through Make's own API and re-enables it when it finds it off. The API pieces are documented in the Make API scenarios reference:
- Create a personal API token. Profile, API tab, "Add token" - give it the scenarios read/write scopes, and note that the watchdog authenticates with
Authorization: Token YOUR_TOKEN. - Create the watchdog scenario with a scheduling trigger every 5-10 minutes, and add an HTTP module:
GET https://eu1.make.com/api/v2/scenarios/TARGET_SCENARIO_ID
Authorization: Token YOUR_API_TOKENThe response includes a scenario.isActive boolean - the exact state Make flipped to false when it disabled the target.
- Add a filter on the next module that continues only when
scenario.isActiveisfalse, then re-enable with a second HTTP module:
POST https://eu1.make.com/api/v2/scenarios/TARGET_SCENARIO_ID/start
Authorization: Token YOUR_API_TOKEN- Alert on the re-enable itself. A scenario that got disabled once will likely get disabled again; send the watchdog's output to Slack or email so the underlying connection gets a human look. The same API supports notifications if you want Make to push events to an external endpoint instead.
Replace eu1 with your zone's base URL (us1, eu2, us2, and similar - it is the host in your browser's address bar while you are in Make). These endpoints are the current API v2 surface as of September 2026. Keep the watchdog's own error handling simple: it has no native modules that depend on the failing connection, so nothing in it triggers an init-time verification of Google at all.
Can you avoid the init-time verification entirely?
Yes - in the critical path, swap the native Google Sheets or Drive module for an HTTP module that calls Google's API with OAuth 2.0. Native app connections get verified before the scenario starts, which is exactly the failing step; an HTTP request happens inside execution, where normal error handling, retries, and resume apply. The thread's OP used this alongside the watchdog for the modules that matter most. It costs you the convenience of the pre-built Google module, so reserve it for the scenarios that cannot afford downtime.
How to set up the watchdog and verify it in 15 minutes?
- Generate a personal API token and note your zone's API base URL.
- Build the watchdog: schedule trigger, GET
/scenarios/TARGET_ID, filter onisActive: false, POST/scenarios/TARGET_ID/start. - Stop the target scenario by hand once and confirm the watchdog flips it back on within one cycle.
- Route the watchdog's output to Slack or email so every re-enable gets reviewed.
FAQ
Why did Make disable my scenario when nothing changed?
Make verified an existing connection at initialization and hit a temporary error on the provider's side (an internal_failure 500). Nothing in your scenario changed; the failure was entirely on the verification call, and Make's default response to it is to disable the scenario.
Does exponential backoff retry AccountValidationError?
No. Make's automatic backoff applies only to ConnectionError and ModuleTimeoutError. AccountValidationError raised at initialization is in neither class, and backoff reruns a failed execution anyway - an init failure never produced one.
Can I catch an initialization error inside the scenario?
No. Error handlers attach to module executions, and initialization happens before the first module runs. Make Support confirmed there is no way inside the scenario to catch or retry an initialization failure.
How many consecutive errors disable a Make scenario?
Three consecutive errors disable a scenario with a scheduled trigger. The init-time failure counts as one, and because no retries run before the disable, a single repeated init failure can take a production scenario offline immediately.
Will the watchdog keep re-enabling a genuinely broken scenario?
Yes, so pair it with alerting. The watchdog restores availability from transient provider errors; the alert is what forces a human to fix the connection, rotate the OAuth grant, or re-authorize when the failure is real.