For over 10 hours, my Gmail Trigger node has been returning the error “The service is receiving too many requests from you” (“User Rate Limit Exceeded”).
Context:
New Gmail account, connected via Gmail OAuth2 API
The workflow was previously polling the inbox every 1 minute, later changed to every 5 minutes
A moderate number of manual node tests over the past few days (not hundreds)
I fully deactivated/unpublished the workflow and made no manual tests for several hours
Logging into this Gmail account directly through the browser works completely normally — no security warnings or unusual-activity notices from Google
Despite complete silence from n8n’s side for hours, the error persisted, and the “retry after” timestamp in the error seemed to keep moving further into the future with each check, rather than getting closer
What I’ve already tried: disconnecting and reconnecting the Gmail OAuth2 credential, reducing the polling interval, fully pausing the workflow for many hours.
Is this a known issue? How can I resolve this permanently?
In Google’s rate-limiting system, if you continue to make requests after receiving a 429 Too Many Requests error, the system views this as “ignoring the limit,” which often triggers a penalty that pushes the lockout period further into the future.
Since you mentioned that you have deactivated the workflow and stopped manual tests, but the timestamp is still moving, it means there is a “hidden” source of requests hitting the Gmail API using your credentials.
Even if your main workflow is off, requests could be originating from:
Zombie Executions: A previous execution might be stuck in a “Running” or “Waiting” state in the background. Check your Executions tab and filter for “Running” or “Waiting” status. If you find any related to Gmail, stop them manually.
Other Workflows: Do you have any other workflows (even disabled ones that might have a trigger active, or separate “test” workflows) using the same Gmail OAuth2 credential?
Multiple Nodes: If you have multiple Gmail nodes across different workflows, they all share the same quota for that user account.
Rapid Token Refresh: If the OAuth2 connection is unstable, n8n might be attempting to refresh the token repeatedly. While token refreshes usually have a different quota, in some cases of severe account flagging, any API call can trigger the 429.
To stop the “penalty timer” from moving forward, you must ensure zero requests are sent.
Delete (don’t just deactivate) the Gmail Trigger node in your workflow temporarily. This removes the polling configuration from the n8n internal scheduler entirely.
Check the Executions tab and kill any active/stuck processes.
Disconnect the Gmail Credential in the Credentials settings. This prevents any background refresh attempts.
Wait 24 hours. Because the timer has been pushed forward, a standard “few hours” break is likely not enough. Google often requires a full 24-hour window of absolute silence to reset the “User Rate Limit” for new accounts.
Once the lockout is lifted, avoid the “Polling Trap”:
Increase Polling Interval: 1 minute is very aggressive for a new Gmail account. Start with 15 minutes or 30 minutes.
Avoid “Test” Spam: Every time you click “Test Step” on a trigger, it performs a request. If you do this 20 times while the API is already struggling, you trigger the penalty.
Use Filters: Ensure you are using the “Filters” option in the node to limit the amount of data returned per poll, which reduces the load on the API.
This is a Google-side rate limit that gets applied against the OAuth token, not the n8n instance or IP. Pausing the workflow stops new requests, but the 429 window Google sets can persist for hours because it counts historical request density on the token, not just live traffic.
A few things that help:
1. Revoke and re-authorize the OAuth credential
Go to Google Account → Security → Third-party access and revoke the n8n OAuth app. Then reconnect from n8n with a fresh OAuth grant. This gives the new token a clean rate-limit slate.
2. Reduce polling aggression
For Gmail Trigger on Cloud, every 1-minute poll against a single account can hit the quota ceiling faster than you’d expect, especially if you were also running manual tests. 5 minutes is safer; 15 minutes is comfortable for most use cases.
3. Switch to Gmail Push notifications if you need near-real-time
Gmail supports pub/sub push via Google Cloud Pub/Sub. n8n has a Gmail Trigger mode for this that uses webhooks instead of polling, so it won’t consume quota at all during idle periods.
If revoking and reconnecting doesn’t clear it within a few hours, your Google account may be flagged for an extended backoff window — not much to do except wait 24h.
Throttle before the API node rather than retrying every failed item together. Add a small batch size, a wait between batches and exponential backoff that respects any Retry-After header so one rate limit does not create a retry storm.
Hey @Damian_Pecio in addition to the mentioned solutions mentioned in this thread, I would also try to create a new app through the google console and from that new app I would try again (connecting for the first time for this new app, OAuth … etc).
