n8n Google OAuth Expires Every 7 Days: The Fix

Glowing threads linking tree roots on a dark forest floor — an illustration of connected automations

Key takeaways

Google issues refresh tokens that expire in 7 days to OAuth apps with user type External and publishing status Testing. That is the weekly n8n disconnect.
The fix is to set the publishing status to In production (or use user type Internal on Google Workspace), then reconnect the credential in n8n. The token you already have keeps its 7-day expiry.
For a personal or small internal setup, you usually don’t need Google’s verification. Expect an “unverified app” warning and a 100-user cap instead.
The error is invalid_grant / “Token has been expired or revoked.” An n8n Error Trigger workflow can alert you the moment it shows up.

Why the credential dies after exactly 7 days

On self-hosted n8n, you connect Google with your own OAuth client. You create it in Google Cloud and paste its Client ID and Secret into n8n. While you set that client up, the app usually sits in Testing, where you list yourself as a test user, and most people never take it out. Publishing status is the Google Cloud setting that decides who can use your OAuth app. Testing limits it to up to 100 listed test users. In production opens it to any Google account.

Google’s OAuth documentation is explicit. A project “with an OAuth consent screen configured for an external user type and a publishing status of ‘Testing’” gets a refresh token that expires in 7 days. Google Cloud’s audience help page says the same thing from the user side: authorizations by a test user “will expire seven days from the time of consent,” and any offline refresh token expires with them.

A refresh token is the long-lived credential n8n stores to get new short-lived access tokens in the background. When it expires, every Gmail, Sheets, Drive or Calendar node that uses the credential starts failing, usually on a scheduled run at a moment nobody is watching. n8n’s own Google OAuth docs describe this case and give the same short answer: reconnect, and fix the publishing status so it doesn’t come back.

Symptom, cause, fix

Not every expired Google token is the 7-day rule. Use this table to match what you see.

Symptom	Likely cause	Fix
Works for about a week after connecting, then `invalid_grant` / “Token has been expired or revoked”	OAuth app is External + Testing	Set to In production (or Internal), then reconnect the credential
Still expires after switching to production	The credential still holds the old 7-day token from before the switch	Reconnect once more after publishing
Breaks after a long quiet period with no runs	Google expires refresh tokens unused for six months	Reconnect; keep at least one periodic run on the credential
Older credentials die when you connect new ones for the same account	Google limits refresh tokens to 100 per Google Account per OAuth client ID	Reuse one credential across workflows instead of reconnecting new copies
Breaks right after a password change (for tokens with Gmail scopes) or a security review	The password change or an admin revoked access	Reconnect; check the account’s third-party access list
“Access blocked” or “Google hasn’t verified this app” when connecting	You aren’t a listed test user, or user type doesn’t match the account	Add yourself as a test user, or publish the app and click through the warning

The six-month, 100-token and revocation rows all come from Google’s list of refresh token expiration reasons. Only the first two rows are fixed by changing the publishing status.

The same credential under each publishing status. Only a token issued after publishing gets the longer life.

The fix, step by step

This takes about two minutes in Google Cloud, plus one reconnect in n8n. Google has moved these settings around over the years; in the current console they live under Google Auth Platform → Audience. Older consoles call the same screen “OAuth consent screen.”

Open the Google Cloud project that owns the OAuth client n8n uses. The Client ID in your n8n credential tells you which one.
Go to Google Auth Platform → Audience.
Check User type. If it says Internal, the 7-day rule doesn’t apply, so look further down the table above. If it says External, continue.
Under Publishing status, click Publish app and confirm. The status should now read In production.
In n8n, open Credentials, open the Google credential, and click Sign in with Google again to reconnect. Approve the consent screen.
If you see “Google hasn’t verified this app,” that’s expected for an unverified app. Because it’s your own app, you can continue past the warning.
Re-run one workflow that uses the credential to confirm it works. Then repeat step 5 for every other Google credential built on the same OAuth client.

The step people skip: publishing does not extend tokens that were already issued. A refresh token handed out while the app was in Testing still carries its 7-day expiry. If you publish and don’t reconnect, the credential fails again within the week and it looks like the fix didn’t work. An n8n community thread about credentials that kept expiring “even in production” lands on the same advice: renew the token once after switching.

Do you need Google verification?

Publishing to production and getting verified are two different things. Moving to In production makes the app available to any Google account. Google then asks production apps that request sensitive or restricted scopes to complete verification. n8n’s Gmail and Drive nodes use scopes like https://mail.google.com/ and https://www.googleapis.com/auth/drive, both on Google’s restricted scopes list.

For a typical n8n setup, you don’t have to go through that review. Google’s “when is verification not needed” page names these exemptions:

Personal use, fewer than 100 users. You can keep using the app unverified. Users see an “unverified app” screen when they sign in, and verification becomes necessary if you grow past 100 users.
Internal use. If only people in your Google Workspace or Cloud Identity organization use the app, there is no unverified app screen and no 100-user cap.
Service-owned data only. Apps that use a service account to reach their own data, not user data, are exempt.
Admin-trusted apps. A Workspace admin can mark an app as trusted regardless of its verification status.

According to Google’s unverified apps page, the 100-user limit counts new users. It starts after the app first shows the unverified app screen. If you are building an n8n-based product where clients connect their own Google accounts to your OAuth client, that is a different situation. Plan for verification, and expect a longer review for restricted scopes.

The Workspace alternative: user type Internal

Does the Google account you connect belong to a Google Workspace organization? Then you can avoid the Testing trap altogether. Google lets projects that belong to a Google Cloud Organization set the user type to Internal, which limits sign-in to members of that organization. The 7-day rule only applies to External apps in Testing, and internal apps skip both the unverified app screen and the 100-user cap.

Two conditions apply. The Google Cloud project has to live inside your Workspace organization, not in a personal Gmail account’s project. And every account you connect in n8n must be in that organization. n8n’s docs put it simply: with Internal, create the OAuth credentials from the same account you’ll authenticate with. A personal @gmail.com account can’t use Internal, so External + In production is the route there.

For server-to-server jobs that only touch data a robot account owns, such as a shared spreadsheet, a service account credential avoids user consent entirely. One n8n community member with this exact problem ended up switching to a service account. n8n still recommends OAuth2 for most cases, though, because not every Google node supports service accounts.

How to detect it before your client does

You’ll see this on the failing node:

"error": "invalid_grant",
"error_description": "Token has been expired or revoked."

invalid_grant is the generic OAuth error for a refresh token that no longer works. Google’s web-server OAuth guide says it means the token “may have expired or has been invalidated,” and the cure is to authenticate again. Use the table above to work out why. Then it won’t repeat.

The Error Trigger is an n8n node that starts a workflow whenever another workflow fails. n8n’s error handling guide builds alerts around it.

Create a new workflow that starts with an Error Trigger node and name it Error Handler. It doesn’t need to be published.
Add an IF node that checks whether {{ $json.execution.error.message }} contains invalid_grant or expired or revoked. Route matches to a high-priority alert and everything else to a general one.
Send the alert by email, Slack or Telegram. Include {{ $json.workflow.name }}, {{ $json.execution.lastNodeExecuted }} and {{ $json.execution.url }} so whoever gets it can click straight to the failed run.
In each production workflow, open Settings → Error workflow and select Error Handler.

Two caveats from the Error Trigger docs. Error workflows only fire on automatic executions, not when you click Test workflow. The trigger node itself can fail too, for example a Gmail Trigger that can’t authenticate. Then the error data has a different shape without execution.url, so make the alert tolerate missing fields. Also, don’t send the alert through the same Google credential that just broke.

Self-hosted vs n8n Cloud

On n8n Cloud, many Google nodes support managed OAuth: you click Sign in with Google and n8n supplies the OAuth app. There is no Google Cloud project of yours to leave in Testing. n8n lists Google Calendar, Contacts, Docs, Drive, Gmail, Sheets, Slides, Tasks, Chat and YouTube (plus the matching triggers) as supporting it on all Cloud plans.

On self-hosted n8n, managed Google OAuth isn’t available. You always bring your own OAuth client, which is why this problem shows up so often on self-hosted instances. It’s also why checking the publishing status belongs in your setup checklist for every new Google Cloud project.

Moving instances, upgrading, or changing your public URL can break OAuth too, because the redirect URL registered in Google must match the one n8n uses. If your webhooks and callbacks broke after an upgrade, see our guides to n8n webhooks that work in test but not in production and n8n 2.0 breaking changes.

Microsoft and Slack: the same problem, different rules

Google’s 7-day rule has no exact twin elsewhere. Other providers’ tokens also expire, though, and the symptom in n8n looks the same.

Microsoft (Entra ID / Outlook / OneDrive / Teams). Refresh tokens default to a 90-day lifetime for most apps, and they replace themselves with a fresh token on every use. A credential in regular use keeps renewing. One that sits idle past its lifetime will need reconnecting. Entra also revokes refresh tokens when a user or admin revokes sessions, and in some cases after an admin password reset. The fix is to reconnect, and to know which account events trigger revocation in your tenant.
Slack. Classic Slack OAuth access tokens don’t expire, according to Slack’s token rotation docs. If token rotation is enabled on the Slack app, access tokens expire every 12 hours and must be refreshed with a refresh token. Slack warns that rotation can’t be turned off once it’s on. If a Slack credential started failing around the time someone changed the app’s settings, check whether rotation was enabled.

FAQ

Why does my n8n Gmail credential keep disconnecting every week?

Your Google Cloud OAuth app has user type External and publishing status Testing, so Google issues refresh tokens that expire after 7 days. Publish the app to In production (or use Internal on Workspace), then reconnect the credential in n8n.

I switched to production but it still expired. Why?

The credential still held a token issued while the app was in Testing, and that token keeps its 7-day expiry. Reconnect the credential once after publishing so n8n gets a new, long-lived refresh token.

Do I need to verify my app with Google to use it in n8n?

Usually not for personal or small internal use. Google exempts personal-use apps with fewer than 100 users and apps used only inside your Workspace organization. Unverified external apps show an “unverified app” warning at sign-in.

Does this happen on n8n Cloud?

Not for nodes that use n8n Cloud’s managed Google OAuth, because n8n supplies the OAuth app. If you connect with your own OAuth client on Cloud, or run self-hosted n8n, the same publishing-status rules apply.

Research method. We fact-check every claim on our blog against primary sources. For this page, that meant checking each claim on October 17, 2026 against the official Google, Microsoft, Slack and n8n documentation listed under Sources. Community threads are cited only for the exact error text and the reconnect-after-publishing gotcha.

Credentials keep breaking and you’d rather not chase them?

Our n8n / Make Workflow Repair service starts with a diagnosis within 24 hours on business days for $149, credited toward the repair. The fixed-price repair starts at $390 and includes error alerts. New customers get 20% off. See all rates on our pricing page.

Get a workflow diagnosis Message us

Sources

VLWritten by the VL Studio team — we build and repair automations, AI receptionists and websites for small businesses in the US and Europe.

n8n Google OAuth expires every 7 days: the 2-minute fix