In a production published workflow, working primarily with the Google APIs, I often get the error:
Forbidden - perhaps check your credentials?
Quota exceeded for quota metric ‘Queries’ and limit ‘Previous quota: Requests per minute’ of service ‘drive.googleapis.com’ for consumer ‘project_number:…’
However, when I go in the instance and run it manually, it always runs without a problem.
There is a scheduled “Master” workflow, that executes the workflow below, and when it goes to the “Find REPORTS Folder” node, it errors out.
Forbidden - perhaps check your credentials?
Quota exceeded for quota metric ‘Queries’ and limit ‘Previous quota: Requests per minute’ of service ‘drive.googleapis.com’ for consumer ‘project_number:<project_num>’.
Information on your n8n setup
n8n version: 2.35.4
Database (default: SQLite): SQLite (using n8n cloud instance, so I guess)
n8n EXECUTIONS_PROCESS setting (default: own, main): own, main
@hinzzx the error message is Google saying the quota limit has been hit for the API they have a few different ones in this case it is the per minute so it could be multiple items going to the node. One possible solution could be to add the retry option to the node or use the error output and add a wait then retry the node.
Jon’s second option is the one that’ll work here. Worth knowing retry is already on those nodes in your JSON, maxTries 5 at 5000ms, which is roughly 25 seconds of retrying and all of it lands inside the same 60 second window that’s already exhausted. That’s why it isn’t helping. The error output plus a Wait longer than a minute is what gets you past a per-minute quota.
The problem is that your Loop runs one client at a time, with about 75 seconds of waiting time for each client, so it doesn’t make many Drive calls per minute. It’s worth checking the project number in the error message. When you connect Drive with Sign in with Google on Cloud, n8n’s managed OAuth is used. This means that the bucket belongs to n8n’s project rather than yours, and other people’s load counts against it. That’s just a guess, but it seems to make sense.
Did you set up your own Google Cloud project for that credential, or use Sign in with Google?
Hi @Lopez The VAT & PAYROLL ones, are firing at different days (between 1st and 15th of the month from 1pm to 4pm), and the REPORTS fire from 21st to 31th of the months at 5PM.
I guess the confusion might come from the screenshots.
The flow is 1-15th of the month (between 1pm and 4pm) → Run VAT & PAYROLL Workflows
21-31th of the Month (at 5pm) → Run REPORTS Workflow at 5pm.
That settles it, thanks. The two times are 1pm and 4pm, and 5pm, so they will never be the same day, even in a month where both date gates pass. My theory about collisions was wrong, so ignore the staggering suggestion.
Which leaves the real pattern: WF3 fails every time the schedule fires it and succeeds every time you run it by hand two minutes later, including the 12 minute run on the 21st that made far more Drive calls than the failing one did. Volume from this workflow isn’t the issue.
One cheap test that would split this cleanly: move the REPORTS trigger to a different hour for a day. If it still fails, time of day is irrelevant and the difference is scheduled versus manual execution, which is a more interesting problem than quota. Still worth answering the earlier question too, what project number shows in the error, and did you create your own Google Cloud project and OAuth client for that Drive credential, or connect it with Sign in with Google?
I have all of that. The nodes are authenticated with the Google’s OAuth.
I couldn’t possibly hit the quota limit, as I just fetch data from Google Sheets, then according to this data proceed to traverse into folders of Google Drive, like Client Name → Reports → 082026 → 082026 → Download files → Send them
Between each of those there is a wait node, to make absolutely sure we do not hit quota limit.
Sign in with Google on Cloud uses n8n’s Managed OAuth2, so the OAuth client is n8n’s project, not yours, and that project number in the error is theirs. The per-minute Drive bucket is shared with other Cloud users on that client. Your call volume reasoning is right, it just isn’t the volume that matters, and wait nodes can’t throttle calls that aren’t yours. Fits your timing too: 17:00:26 fails both days, 17:02 and 17:03 succeed both days, and the top of the hour is when everyone’s schedules fire.
Fix is moving that credential to Custom OAuth2 with your own Google Cloud project. Then the bucket is yours and you can raise it if needed. Moving REPORTS to 5:07pm might help in the meantime, different reason from the staggering idea I retracted.
Since it fails on the scheduled run but succeeds manually a couple minutes later, I’d avoid treating this as a normal credential problem first.
Two practical checks I’d do: log the exact timestamp before every Drive node in the child workflow, and cache stable folder IDs instead of searching Drive every run if those folders do not move. Folder search/list calls are easy to forget about, but they still spend the same quota bucket.
If you add a wait/retry path, I’d make it longer than the quota window and preserve the client/report ID so the retry can resume the same unit of work instead of starting the whole report chain again.
Hi @hinzzx
A consent screen left at Publishing status “Testing” with User type “External” expires the refresh token after seven days, so once that Drive credential is on your own OAuth client the schedule runs for a week and then starts failing on auth rather than quota. On the Audience page in Google Auth Platform, set Publishing status to “In production” before you reconnect the credential, and click through the unverified app warning when it shows.
