Why Your Automation Keeps Asking You to Reconnect

An automation that asks you to reconnect an account almost never broke on the schedule you were told to expect. The refresh token lifetimes vendors advertise, 90 days at Microsoft, 100 days at QuickBooks Online, 60 days at Xero, are outer bounds, not failure points. What actually kills connections is a refresh token that rotated to a new value your side did not save, or an automation that ran too rarely to keep its token alive. Neither of those lands on a renewal calendar, which is why the only advice anyone ever gives you is to click reconnect one more time.

This is worth getting right because a dead connection is the most expensive kind of quiet failure. The flow does not error loudly on step four. It stops at step one, so nothing downstream runs, nothing is half-written, and nothing looks wrong until someone asks where the leads went. It belongs in the same category as the other ways automations break silently, except this one has a fix you can apply before it happens.

What actually kills an automation's connection

There are four triggers. Only one of them is a clock.

Trigger	What it looks like from the operator's seat	Would a calendar reminder have caught it?
Rotation loss	Worked yesterday, dead today, nobody changed anything	No. It fires on a failed write, not a date
Idle expiry	The quarterly flow is broken again, the hourly one is fine	No. It depends on run frequency, not age
App still in Testing status	Every Google connection dies on day seven, forever	No. It is a project setting, not a lifetime
Human or tenant event	It broke the morning after a password change or an offboarding	No, but an ownership audit would have

Notice the pattern. The advertised token lifetime does not appear anywhere in that list. Teams that respond to repeated disconnections by putting a reauthorization reminder on the calendar are solving a problem they do not have, and they will keep reconnecting on the same unpredictable cadence they always did.

The rotating token is the one that breaks permanently

Here is the distinction almost nobody makes, and it decides which of your connections is fragile.

An expiring refresh token fails politely. It works until a known date, then stops, and reauthorizing resets the clock. Google works this way for an app in production status, and so does Microsoft: its identity platform docs put the default refresh token lifetime at 90 days for most scenarios, note that refresh tokens are not revoked when used to get a new access token, and randomize access token lifetime between 60 and 90 minutes to spread load. Miss a refresh and you can try again with the same token.

A rotating refresh token is different. Every successful refresh hands back a new value and retires the old one. Get the new value stored and you are fine forever. Fail to store it once and the connection is dead permanently, because the token you hold is a token the provider has already thrown away. QuickBooks Online is the clearest example of how misleading the headline number is: Intuit documents the refresh token as valid for 100 days, but the value itself is reissued roughly every 24 hours and the previous one expires when the new one arrives. The number that matters is 24 hours, not 100 days. Xero rotates on every single refresh, expires unused refresh tokens after 60 days, and gives you a 30 minute window to retry with the old token if you never received the response. Slack, with token rotation turned on, expires access tokens every 12 hours and revokes each refresh token as it is used.

Four situations snap a rotating chain, and all four look like something else in the logs:

1. A run died between the refresh call and the write. The provider issued a new token, your side never persisted it. The next run authenticates with a retired value.
2. Two workers refreshed at the same moment. One stores a valid token, the other stores a token that was invalidated a second later. This is exactly the case Xero's 30 minute grace period exists to absorb.
3. You restored a backup or reverted a container. The restore puts back a refresh token value from Tuesday. It is now Friday and that value has been retired four times over. This one bites hardest on self-hosted n8n, and it is worth folding into how you roll back a broken automation, because a rollback that restores credential storage is an auth event, not just a code event.
4. You cloned the flow to a staging environment. Two copies now refresh the same credential against each other, and whichever one runs second holds a dead token.

If you take one thing from this article: sort your connections by whether the provider rotates, and treat the rotating ones as state you are responsible for persisting correctly, not as a setting you configured once.

Why the automation you run once a month breaks first

This one is counterintuitive enough that people misdiagnose it for years. Several providers expire refresh tokens on disuse rather than on age. Google's OAuth documentation lists "the refresh token has not been used for six months" as a reason a token stops working. Xero expires unused refresh tokens after 60 days.

The consequence: your busiest automation is your safest one. A flow that fires every fifteen minutes refreshes constantly and can hold a connection open for years. A month-end close, a quarterly compliance export, an annual renewal notice, those are the ones that cross the idle threshold, and they are also the ones where a failure costs the most because nobody is watching that week.

The fix is a heartbeat, and it is cheap. Schedule one harmless authenticated read per connection on a weekly cadence: fetch one row, list one folder, call the identity endpoint. It keeps the token warm and, because you can alert on it, it converts a silent authorization expiry into a signal. That is the same pattern as alerting when an automation stops running, applied to credentials rather than executions.

How long each connection actually lasts

Current as of July 2026, from each vendor's own documentation. The last column is the one to plan around.

Provider	Advertised refresh token life	Rotates on refresh?	What actually breaks it first
Google (Gmail, Sheets, Drive)	No fixed expiry in production status; 7 days if the consent screen is in Testing	No	Testing status, six months unused, a password change when Gmail scopes are granted, or exceeding 100 refresh tokens per account per client ID
Microsoft Entra (Outlook, Teams, SharePoint)	90 days default; 24 hours for single page apps	New one issued, old one stays valid	Conditional Access policy, password reset, admin consent change
Slack (token rotation on)	Refresh token single use; access token 12 hours	Yes, revoked on use	Any missed rotation
Xero	60 days unused	Yes, every refresh	Idle past 60 days, or a lost rotation past the 30 minute retry grace
QuickBooks Online	100 days	Yes, new value roughly every 24 hours	A stale stored token, long before day 100

That Google row deserves special attention if you self-host. Anyone who created their own Google Cloud OAuth client for an n8n instance and left the consent screen in Testing gets a refresh token that expires in seven days, permanently, on every Google credential in the instance. It is not a token problem and no amount of reconnecting fixes it. Publish the app and the seven day limit goes away.

Your platform tells you late, and sometimes not at all

Once a connection dies, the recovery path depends on a platform behavior most teams have never read.

Zapier turns a Zap off automatically when it has run more than 20 times in the past seven days and errors 95 percent of the time. Team and Enterprise accounts get an email and a grace period first, 24 hours and 72 hours respectively. Below those plans there is no grace window, so the first notice is a Zap that is already off, and every trigger event that arrived while it was off is gone. On self-hosted n8n the credential error surfaces per execution, which means it only surfaces if something is watching executions. Make routes the failures to incomplete executions, where they sit until someone opens the queue.

In all three cases the platform reports the outage after it has already cost you runs. Detection has to come from your side.

Where to start: the 20 minute connection inventory

Open your automation platform and list every connected account. For each one, write down four things: which provider it is, whose login it was authorized with, whether that provider rotates refresh tokens, and how often a flow using it actually fires.

Two columns tell you almost everything. Any connection authorized with a personal account belonging to someone who could leave the company is a scheduled outage with an unknown date, and it should be moved to a service account this week. Any rotating provider attached to a flow that runs less than weekly is the pair most likely to break next, and it gets a heartbeat.

Most operators find between two and five connections that fit one of those descriptions, and in our experience the personal-account one is the more expensive of the two, because it takes down several flows at once and it always happens during someone's last week. If you want the whole set audited alongside the flows that depend on it, tell us what you are running and we will map it with you.