n8n 憑證到期造成工作流靜默失效的原因與預防做法

This is part of my build-in-public series on running LLM workflows in n8n in production. Everything here is from real templates I sell and support — the mistakes are mine, the fixes are tested.

The workflow was fine. The credential was not

A workflow of mine pulled new rows from a CRM every hour, enriched them with an LLM call, and wrote the results back. It ran clean for months. Then one Saturday morning it stopped writing. No node was red. The executions showed "success" — because the workflow's error path caught the failed API call, logged it, and moved on. The log said, in small print, 401 Unauthorized.

The OAuth token had expired. The refresh token had expired too, silently, weeks earlier — the provider rotates refresh tokens after ninety days of inactivity on that grant, and nobody had re-authorized. The workflow did not fail. It just stopped doing its job, politely, one "successful" execution at a time.

Credential expiry is the quietest production failure there is. It does not look like a bug. It looks like nothing happening. And it always seems to happen on a holiday, because that is when nobody is watching the dashboard.

Expiry is a schedule, not a surprise

The fix starts with treating every credential as something with a known expiry date, not as a permanent fact. For each credential my workflows depend on, I record three things in one place: what it is, when it expires (or when it must be re-authorized), and who owns re-authorizing it. OAuth grants with rotating refresh tokens get a calendar reminder two weeks before the rotation window. API keys with fixed expiry get the same. Keys that "never expire" get a quarterly check anyway, because providers change policies without asking you.

This list lives outside n8n. If the credential that lets the workflow talk to the provider is dead, a workflow cannot be the thing that tells you — it has no way to reach you through the same dead channel. The expiry list is a boring spreadsheet, and it has saved me twice.

Separate "auth failed" from "request failed"

The second fix is inside the workflow: never let an authentication failure travel down the same path as a transient failure. A 429 or a 500 means "try again later." A 401 or 403 means "your permission is gone, retrying will not help, and every retry is wasted work that hides the real problem."

In my workflows, the HTTP node that talks to an external API is followed by a check on the status code before anything else happens. Auth failures go to a dedicated branch: stop the workflow, send an alert that names the credential and the provider, and mark the run as failed — loudly. Transient failures go to the retry branch. The rule is simple: a retry loop must never be allowed to chew through an auth failure for hours while reporting success.

This also means the error workflow from my earlier canary article has to know the difference. "Workflow failed" is not enough. The alert must say "authentication failed for this credential," because that is the sentence that gets a human to re-authorize instead of re-running.

Re-authorization is a runbook, not a memory

The third fix is the least technical and the most important: re-authorizing must be a written procedure someone else could follow. Which account owns the grant, where the login lives, what scopes it needs, what breaks while it is down, and how you verify it is back — all written down before the expiry, not reconstructed at midnight while the workflow is silent.

I learned this the hard way: the first time a token expired, I spent an hour figuring out which of three accounts owned the grant, because the credential name in n8n was "CRM Prod" and the login belonged to an inbox I rarely opened. Now the credential name includes the owner account, and the runbook names the inbox. Boring, and it turns a holiday outage into a ten-minute task.

The principle

Workflows do not run on code alone. They run on permissions granted by other systems, and every permission has a clock on it. If you do not track the clock, separate auth failures from transient ones, and write down how to renew, your automation has a built-in expiry date — and it will arrive on the day you least want it to.

I'm building AI Automation Lab — production-ready n8n workflow templates. The free AI Hook Generator shows how I structure real workflows; my open-source templates live at github.com/zhp910318/n8n-ai-automation-lab.