n8n Automation Hub
Every other bug on this site had an API fix. This one doesn't.
Most of the real bugs documented on this site — 503s, rate limits, malformed messages, misconfigured nodes — get fixed the same way: read the live workflow via the n8n API, change the one thing that's wrong, write it back, confirm with a fresh read. That pattern breaks down completely for one specific error class, and it's worth being honest about why, because it's a real limitation anyone running n8n against Google or other OAuth-based services will eventually hit.
The Avail Get Masters node in the calendar-booking demo — a Google Sheets read that checks which staff or resources are available before offering booking slots on a public-facing webhook — started failing on essentially every call with: "The credential 'Google Sheets account' needs to be reconnected." Since this node sits near the top of the booking flow, every webhook hit downstream of it fails the same way, which for a live demo means the booking page simply stops working.
What this error actually means
n8n's own description is specific: "Access could not be refreshed because the connected account has revoked access, the refresh token expired, or the account password or permissions changed." An OAuth2 credential like this one doesn't store a permanent password — it stores a refresh token that n8n uses to mint short-lived access tokens on demand. When Google invalidates that refresh token — because access was manually revoked in the Google account's security settings, because the token aged out, or because something about the account's security state changed — every future refresh attempt fails, and there is no data left in n8n that can regenerate a valid one. A new refresh token can only come from the user completing Google's OAuth consent flow again, in a real browser, for that specific Google account.
This isn't unique to this one workflow. The same day, a completely unrelated workflow on this instance — WF - German News Channel — hit the identical error class on its YouTube upload credential: The credential "YouTube - German News Channel" needs to be reconnected, same underlying description. Two different credentials, two different Google API products, same root cause category. That's a useful signal on its own: when this error shows up, it's worth checking whether other OAuth credentials on the same Google account are affected too, rather than assuming it's isolated to the one workflow that happened to be the first to notice.
Why the API can't fix it
The n8n public API can read a credential's metadata and can update most of what a workflow node does, but it has no endpoint that performs an OAuth authorization-code exchange on a user's behalf — that flow requires a browser redirect to Google's consent screen, the user clicking "Allow," and Google redirecting back with a fresh authorization code. There's no way to script around that step; it's a deliberate part of how OAuth is designed to work; a service that could silently regenerate its own access to a Google account without a human in the loop would defeat the purpose of the consent screen entirely.
Where this stands
Unlike the rest of this site's articles, this one isn't reporting something already fixed. As of this check, the calendar-demo booking flow is still failing at the availability-check step, and the German News YouTube upload credential is in the same state. Both need a manual reconnect through n8n's credential UI, logged in as whichever Google account each credential belongs to. Nothing about this required rewriting a node, adding a retry, or changing any configuration — retries don't help here, since a revoked refresh token fails identically on every attempt. This is simply the one class of n8n failure that ends at "someone needs to log into Google," documented honestly rather than skipped because it doesn't have a tidy before/after fix to show.