For the past few days, I’ve been consistently getting the following error on my scenarios using the Google Sheets module:
Couldn’t connect
[503] The service is currently unavailable.
Code: ConnectionError
Origin: Google Sheets
This error happens randomly but frequently enough to break my automated workflows.
Is anyone else experiencing this recurrent issue recently? Is this a known API rate limit / server-side issue on Google’s side, or something related to Make’s connection handling?
What are the best practices or workarounds to mitigate this? I would like to not set up an error handler with an automatic Break / Retry directive, is there another more durable fix?
I would separate this from rate limiting first. Google Sheets quota failures return 429 Too Many Requests. The error you posted is 503 Service Unavailable, so quota is unlikely to explain this specific failure.
A 503 does not always mean a random Google outage. Google’s Sheets documentation also lists request complexity and spreadsheet complexity as possible causes. Since you do not want a Break or Retry handler, open one failed execution and count the Google Sheets operations in that run.
If an Iterator creates one Sheets request for every row, reduce the calls. Read the needed range once, process the data in Make, and use a bulk action module if the operation supports it. This cannot guarantee that Google will never return 503, but it removes many separate calls and is the most durable change available in that case.
If the run has only one or two Sheets calls, the Iterator explanation does not fit. Try the same module and a similar range on a small clean spreadsheet. If that is stable while the original sheet fails, check whether the original is large or formula heavy, and whether multiple scenarios use it at the same time.
Also check whether the failing step only reads or can write. Repeating a read normally has no data side effect. Repeating an append can create a duplicate. If earlier write modules completed before a later step failed, rerunning the scenario can repeat those writes, so give writes a stable row key or another duplicate check.
If unrelated spreadsheets fail in the same time window, or these checks do not explain it, save the failed execution IDs and exact timestamps for Make support. A 503 code alone cannot tell you which service caused it.
Yeah, that’s what makes me think it’s less likely to be a workflow design issue. If simple read/write operations are throwing random 503s, I’d lean toward intermittent Google API availability or something in the Make ↔ Google connection layer rather than rate limits.