How the quota is actually measured
| Limit type | Read requests | Write requests |
|---|
| Per project, per minute | 300 | 300 |
| Per user, per minute | 60 | 60 |
| Per day | No fixed cap, as long as per-minute limits are respected | No fixed cap, as long as per-minute limits are respected |
Why a modest-looking workflow can hit this fast
The per-user limit of 60 requests per minute is the one n8n workflows trip most often: a Loop Over Items pattern firing one Sheets API call per row processes 60 rows in roughly a minute at full speed with no pacing — a sheet with a few hundred rows updated in one run can burn through the allowance in seconds if the loop has no delay at all. This is distinct from a one-time overload; the bucket resets every minute, so a 429 is a signal to slow the request rate temporarily, not evidence of a broken integration or an account-level block.
Note also that a batch request (multiple operations sent together) is counted as one API request toward the limit, not one per sub-operation — which is exactly why using n8n's batch/bulk operations where available, instead of one call per row, is one of the most effective ways to stay under the per-minute ceiling.
Two complementary fixes: batch size and retry behavior
- Reduce batch size but prefer true batch operations over per-row calls: n8n's Google Sheets node defaults to a batchSize of 500 rows per call for bulk operations; a batch counts as one request regardless of its internal row count, so use the node's batch/append-many operations rather than looping a single-row update per item wherever the workflow logic allows it.
- Use Retry On Fail with a wait time set longer than the rate-limit window: enabling the node's built-in Retry On Fail toggle with a "Wait Between Tries" value set above 1000ms (since the quota resets on a rolling per-minute basis) lets a single 429 recover automatically instead of failing the whole run.
- Use Loop Over Items with an explicit Wait node between iterations only when per-row calls are unavoidable, spacing requests to stay under 60/minute per user rather than firing every row's request as fast as the workflow engine allows.
// Retry On Fail settings on the Google Sheets node:
{
"retryOnFail": true,
"maxTries": 3,
"waitBetweenTries": 2000 // milliseconds — above the per-minute reset granularity
}
Verify the fix on a realistic batch size, not a small test
Test with a batch close to your real production volume, not a 5-row sample — quota exhaustion is a volume-dependent failure, so a small test can pass while the real workload still fails. Watch the execution log for any 429 retries actually firing and succeeding on retry, which confirms the Retry On Fail configuration is doing real work rather than being unused.
If multiple workflows on the same n8n instance and Google Cloud project all touch Sheets concurrently, remember the per-project limit (300/minute) is shared across all of them — a fix that works in isolation can still fail when several workflows run at overlapping times, so account for total concurrent usage, not just one workflow's own volume.
Sources checked for this guide
Google's own Sheets API limits documentation sets the exact numeric quotas; n8n's rate-limit handling guidance describes the two mitigation approaches used here.
Frequently asked questions
Is a 429 from Google Sheets a permanent block on my account?
No. It is a per-minute rate limit (60 requests per user, 300 per project) that resets automatically. The fix is spacing out or batching requests, not resolving an account restriction.
Will just adding a fixed Wait node between every call fix this reliably?
It helps but is not the most efficient fix on its own — combining true batch operations (which count as one request regardless of row count) with the node's built-in Retry On Fail handles bursts more reliably than a single fixed delay.
Why did this start happening after I updated n8n, with no change to my workflow?
Some reported cases trace to a version-specific change in how the Google Sheets node batches requests internally. Check your installed version's release notes for Google Sheets-related fixes around the version where the behavior changed.
Does running multiple workflows at once make this more likely?
Yes — the per-project quota (300 requests per minute) is shared across every workflow using the same Google Cloud project's credentials, not allocated separately per workflow, so concurrent workflows compound toward the same ceiling.
