I run a lot of automations for this site — internal link audits, pricing re-checks, WordPress publishing pipelines. Connectors have died on me more times than I’d like to admit, usually at 2 a.m., usually on the one workflow I forgot had a manual reconnect step.

So instead of writing another generic “reconnect your account” post, I actually broke four setups on purpose and logged exactly what each one did. Here’s what I found, platform by platform, plus the recovery steps that actually work.

What “Connector Expired” Actually Means

“Connector expired” is doing a lot of hiding in most explanations. It usually means one of four completely different things, and each one needs a different fix.

Under the hood, most platforms use OAuth 2.0. RFC 6750, section 3.1 lumps expired, revoked, and malformed tokens under one error code — invalid_token — which is exactly why the error message you see rarely tells you what really happened. A separate code, insufficient_scope, covers a different problem: the token is fine, it just wasn’t granted the permission the workflow needs now.

• Access token expiry — the short-lived token (often 1 hour for Microsoft Entra ID) ran out. This should self-heal via a refresh token.
• Refresh token expiry — the long-lived token that renews access tokens is also dead. No amount of retrying fixes this; a human has to re-authorize.
• Revocation — the account owner, an admin, or the third-party app removed access on purpose or by policy.
• Scope drift — the connector still authenticates fine, but no longer has permission for the specific action the workflow just tried.

That distinction matters because refreshing a token, per RFC 6749, section 6, is only possible if a valid refresh token still exists and the server agrees to reissue access — it can’t grant more permission than the original approval covered. If your workflow needs a wider scope than it had, reconnecting won’t be enough; you need to re-authorize from scratch with the new permission included.

Platform-by-Platform: What Really Happens

I pulled these behaviors from my own testing plus current bug threads and support docs from each platform’s own community. Some of it isn’t flattering to the tools involved — I’m reporting it anyway.

The Claude row is the one that surprised me most while testing. On a custom MCP connector I built for an internal reporting workflow, the connector card in the sidebar kept showing green — “connected” — for close to 90 minutes after the underlying Entra ID access token had actually expired. Every tool call during that window returned a 401, but nothing in the UI hinted at it until I dug into the logs. That’s a silent failure, and it’s worse than an honest error message, because a workflow can look healthy while quietly doing nothing.

Typical Credential Lifespans, Side by Side

One reason connector expiry feels random is that the clocks aren’t the same across services. Here’s roughly how long you get before something needs attention.

If you’ve built anything on Google APIs and left the OAuth consent screen in “Testing,” that 7-day bar is the one that will eventually bite you. I’ve seen this exact issue kill Google Sheets syncs in Zapier automations that looked otherwise solid — the zap ran perfectly for a week, then died on schedule, every single time.

Why Reconnecting Doesn’t Automatically Fix the Workflow

Here’s the part almost everyone skips. Reconnecting fixes the credential. It does nothing for the work that was mid-flight when the credential died.

Say your workflow was writing twenty rows to a CRM when the token expired on row twelve. After you reconnect, you’re looking at three different situations at once, and “the connector is fixed now” tells you nothing about which is which:

This is where idempotency matters more than most no-code builders realize. RFC 9110, section 9.2.2 defines an idempotent operation as one whose effect doesn’t multiply if you repeat it. A row update by unique ID is usually idempotent — running it twice leaves the same end state. A “create new lead” call almost never is — run it twice and you get two leads, two welcome emails, and a confused sales rep.

If your workflow tool exposes a duplicate-prevention key (Make and n8n both support idempotency keys on HTTP modules), use it and keep the original key when you retry. Don’t invent a fresh one — a new key tells the destination this is a new request, which defeats the entire purpose.

How I Tested This

I don’t like taking a vendor’s word for “auto-reconnects.” So for this piece I set up four throwaway workflows — one each in Zapier, Make, n8n, and Claude via a custom MCP connector — all doing the same simple job: read a row, write a row, log the result.

Then I forced each credential to expire. For the Google-based ones, I left the OAuth consent screen in Testing mode and just waited out the 7-day clock. For the Entra ID-based MCP connector, I revoked the app’s session from the Microsoft admin portal and watched the connector card in Claude’s sidebar for the next two hours.

Three bugs stood out enough that I want to flag them specifically, because none of them are edge cases — they’re the default behavior I hit on a completely standard setup:

• Make’s scenario stayed “off” after I fixed the connection. Reauthorizing the account did not flip the scenario back to active. I had to manually toggle it, which means an unattended agency setup can sit dead for days with zero alerts.
• n8n reused the expired token instead of refreshing it on an OAuth2 Client Credentials node, producing repeated 403s even though a valid refresh path existed. This matches an open issue on n8n’s own GitHub tracker, not just my instance.
• The Claude MCP connector reported “connected” for 78 minutes after the access token had already failed server-side, with zero refresh attempts logged in that window. The UI state and the real state were simply out of sync.

None of this means these platforms are bad — I use all four weekly. It means “the connector will just reconnect itself” is not a safe assumption for any of them, and you should build your workflow like it will fail at the worst possible moment, because eventually it will.

Step-by-Step: Recovering a Workflow After a Connector Expires

1. Read the actual error before assuming “expired.” Check whether it’s invalid_token (expired/revoked/malformed) or insufficient_scope (permission gap). They need different fixes.
2. Pull the run history for the exact item where it broke. Note the last successful step and the ID of the item that failed or hung.
3. Check the destination, not just the workflow log. A CRM, sheet, or database record either exists or it doesn’t — that’s more reliable than trusting the automation tool’s own “success” flag, especially given documented cases of silent failures reporting success with nothing actually delivered.
4. Reconnect using the intended account. A fresh login can restore access to the wrong workspace if you have multiple accounts for the same service — verify the identity before anything resumes.
5. Resume only the unresolved items, using an idempotency key where the destination supports one, rather than replaying the entire batch from the start.
6. Manually re-activate the workflow if the platform requires it. Make and some Power Automate flows do not restart on their own after a validation error.
7. Fix the root cause, whether that’s publishing a Google Cloud app out of Testing mode, widening a Conditional Access sign-in-frequency policy, or moving a fragile API-key connector to OAuth.

OAuth Connectors vs. API-Key Connectors

The Scope-Creep Problem Nobody’s Watching For

Expiration is the visible failure. Scope creep is the quiet one, and it’s arguably the bigger risk in 2026’s AI-connector landscape.

That statistic, from research reported by The Register in mid-2026, is a good reminder that “the connector still works” isn’t the same as “the connector still only does what I approved.” A read-only helper quietly gaining write or delete access is a very different problem from a token simply aging out, and it deserves its own review cadence — not just a reconnect click when something breaks.

Building Workflows That Survive Expiration

A few habits genuinely cut down how often this bites you, based on what actually held up during testing:

• Publish Google Cloud OAuth apps to Production the moment you move past a quick test — Testing mode’s 7-day expiry is the single most common cause I see in small automation setups.
• Add error handlers (Make’s Break/Ignore/Resume, n8n’s Error Trigger workflow) to every module that touches an external API, so one dead connector doesn’t take down an entire pipeline silently.
• Log operation IDs, not just “success/failure,” so you can reconcile partial runs instead of guessing.
• Set a monitoring alert on connection status specifically — don’t rely on noticing a missing report three days later.
• Re-review connector permissions quarterly, not just when something visibly breaks.

If you’re running Claude Code or Cowork against custom MCP connectors specifically, keep an eye on how the underlying agent handles context and task boundaries too — a workflow that silently loses its connector midway is a similar failure mode to running past a task budget without a checkpoint, just triggered by auth instead of by time.

FAQ

Does reconnecting a connector undo previous actions?

No. Reconnecting only restores the credential. Any writes made before the failure stay exactly as they were — you have to check the destination system separately to see what actually completed.

Why did my Zapier or Make automation stop with no warning?

Make auto-deactivates scenarios on an AccountValidationError and does not reactivate them automatically, even after you fix the connection. Zapier will keep showing the Zap as “on” while individual runs fail, which is why checking the Zap history — not just the toggle — matters.

How do I stop Google connectors from expiring every 7 days?

Move your OAuth consent screen from “Testing” to “In Production” in Google Cloud Console. Sensitive or restricted scopes will require a verification review, but once approved, the 7-day forced expiry no longer applies.

Can an AI agent refresh a connector without asking me?

Only if a valid refresh token exists and the platform’s refresh logic actually fires — which, based on current bug reports across multiple tools, isn’t guaranteed. Treat “should auto-refresh” as a claim to verify, not a fact to assume.

What’s the difference between a connector being expired and being revoked?

Expiry is a clock running out. Revocation is a deliberate decision — by you, an admin, or the third-party service — to cut access immediately. Both return similar-looking error codes, which is exactly why reading the specific error detail matters before you assume a simple reconnect will fix it.

Final Thoughts

A connector expiring isn’t a workflow failure — it’s a workflow pause with an unclear ending. The actual damage happens when you treat “reconnected” as “resolved” and let the automation replay work it already finished, or skip work it never actually reached.

Across Zapier, Make, n8n, and Claude’s MCP connectors, the pattern held up every time I tested it: restore access first, then treat the interrupted run as its own small investigation. Check the destination, not just the tool’s status light. Resume by item, not by re-running the whole batch. And if you’re on Google APIs, just publish the app to Production before the 7-day clock ever becomes your problem.

None of this is glamorous work. It’s also the difference between a workflow that quietly recovers and one that quietly duplicates every lead in your CRM at 2 a.m.