Vivere / Answers

n8n Google credential expires every 7 days: why, and the fix

A Google credential that needs reconnecting once a week is almost always an OAuth app left in Testing. One setting in Google Cloud ends it.

The pattern is easy to recognise once it has happened twice. A Gmail, Google Sheets or Google Drive node that worked all week starts failing. You open the credential, sign in with Google again, everything works, and seven days later it breaks the same way. Nothing is wrong with n8n or with the credential. Google is doing what it says it does with an OAuth app that is still in Testing.

What you see

The Google node fails with an error from the token refresh, usually worded like this:

The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.

Every workflow that uses that credential fails from the same moment, because they share the one token it holds. Reconnecting fixes them all at once, which is what makes a weekly rhythm easy to live with and easy to stop noticing.

Why it is seven days

On a self-hosted n8n, a Google credential uses an OAuth client you create in your own Google Cloud project, and that project's consent screen has a user type and a publishing status. If you followed n8n's setup guide without a Google Workspace organization, the user type is External and the app is in Testing, which is why the guide has you add yourself as a test user.

Google's OAuth documentation is specific about that combination: a project with an External user type and a publishing status of Testing is issued refresh tokens that expire in seven days, unless the app asks only for the user's name, email address and profile. Gmail, Sheets and Drive always ask for more, so the token n8n stores stops working a week after you signed in. n8n's own credential page says the same: for such an app, consent and tokens expire after seven days. Testing also limits the app to the 100 test users listed on it.

The fix: publish the app

1. In the Google Cloud console, open the project that holds n8n's OAuth client and go to its Audience page, where the user type and publishing status are set.
2. Under Publishing status, press Publish app. The status becomes In production.
3. In n8n, open each Google credential that uses that client and sign in with Google once more. The token it holds now was issued while the app was in Testing, so replace it with one issued after the change.

Nothing else in the credential changes: the same client ID, the same secret, the same redirect URL.

Does publishing need Google's verification?

For a personal n8n, no. Publishing is a switch; verification is a separate review, and Google lists the cases where it is not needed. Two of them cover most n8n setups:

• Personal use. An app for your own use, with fewer than 100 users, can keep running unverified. Whoever signs in sees Google's unverified-app warning first, and an app that shows that warning is capped at 100 new users in total. For one person connecting their own Gmail to their own n8n, the warning at sign-in is the whole cost.
• Internal apps. If the project belongs to a Google Workspace or Cloud Identity organization, set the user type to Internal. Only people in your organization can sign in, there is no verification and no warning, and the seven-day rule, which is written for the External user type, does not apply.

Verification comes in when the app is for people beyond that: an External app that people outside your organization will sign in to, such as clients connecting their own Google accounts to an n8n you run. Plan for Google's review before you rely on that setup.

Or use a service account

A service account is a Google identity for software. It authenticates with a private key rather than a sign-in, so there is no refresh token to expire. n8n supports it on many Google nodes, including Google Sheets, Google Drive, the Google Drive Trigger, Google Docs and BigQuery, and it has limits worth knowing first:

• It reaches only the files and folders shared with the service account's email address, so share the spreadsheet or folder with it as you would with a colleague.
• n8n's documentation notes that Google no longer lets service accounts created after 15 April 2025 reach My Drive; they have access to shared drives only.
• Gmail works with a service account only through domain-wide delegation, which a Google Workspace super administrator has to set up and which lets the account act as any user in the domain. n8n recommends OAuth for Gmail instead. The Gmail Trigger and Google Calendar have no service-account option at all.

For a personal Gmail account, publishing the OAuth app is the fix. For Sheets and Drive in a Workspace with shared drives, a service account is often the tidier one.

If it still expires, but not weekly

Publishing removes the seven-day rule, not every reason a refresh token stops working. Google also ends one when the user revokes the app's access, when the token has not been used for six months, when the user changes their password and the token carries Gmail scopes, and when an account goes over 100 live refresh tokens for the same client. The error in n8n reads the same in every case, so the interval is the clue.

Hearing about it before your workflows go quiet

An expired token is one of the failures n8n can report itself. A Gmail, Sheets or Drive node that runs with it fails the execution, and so does a Google trigger: in n8n's source, a polling trigger such as the Gmail Trigger, the Google Sheets Trigger or the Google Drive Trigger that throws on a poll records a failed execution and runs the workflow's error workflow. So give each workflow an error workflow, one that starts with an Error Trigger, under Error workflow in its settings. Two things decide whether that reaches you:

• It is set per workflow. A workflow without one fails into the executions list and nowhere else.
• Its alert must not depend on the credential that just expired. An error workflow that emails you through the same Gmail credential fails with the same error, so send it some other way.

What an error workflow cannot report is a run that never happened, and it lives on the same instance as everything it reports on. A heartbeat covers both, from outside n8n. For a scheduled workflow, put a ping after the Google nodes: the week the token expires, the run fails before the ping, the ping does not arrive, and you are alerted whether or not an error workflow was set and whether or not the instance was up to send one.

A workflow started by a Google trigger runs only when there is a new email, row or file, so a missing ping there is as often a quiet day as a dead token. A small canary does better: a workflow on a Schedule Trigger once a day that makes one cheap call with the same credential, such as reading a single row, then pings its own monitor. When the token expires, the canary fails, its ping stops, and the monitor, named after the credential, tells you which one to reconnect before the real workflows have missed much.

The n8n guide sets up the ping with the Vivere node or an HTTP Request node. Vivere's free plan covers 25 monitors.

Common questions

Last reviewed October 2026.

Related

• How to get an alert when an n8n workflow doesn't run — n8n tells you when a workflow fails, not when it does not run: an unpublished workflow, a schedule lost to a restart, a webhook nobody calls, an instance that is down. What n8n offers on its own, where each part stops, and the dead man's switch that covers the rest.
• n8n workflow succeeded but did nothing: catching runs with 0 items — An n8n execution says Success but handled no items: an empty API response, a Filter that dropped everything, a renamed field. Why n8n counts it as success, how to make it fail with Always Output Data, an If node and Stop and Error, and how a heartbeat can alert on a run that handled 0 items.
• n8n Schedule Trigger not firing: what to check — Your n8n Schedule Trigger stopped running. Activation state, timezone, missed executions after a restart, queue mode, and how to be told when a workflow goes quiet.