1. Refresh token gets revoked, rotated, or hits idle TTL.
2. Your background sync keeps retrying.
3. The first real signal is a customer saying “sync stopped working.”

invalid_grant is usually that moment — and most product metrics never see it. 2. Never hold the refresh token in the canary if your product already owns OAuth 3. Alert on:

• 7 / 3 / 1 days before known expiry
• Spikes of invalid_grant (or equivalent) by provider

1. Attach a drafted re-auth email so CS/ops isn’t inventing copy at 5pm Friday

That’s enough to turn “support discovered it” into “we pinged Slack yesterday.”

DIY vs a tiny tool

A 20-line cron over your connections table is totally fine. The canary only earns its keep if:

• you have many customer connections
• expiry + error classes are scattered across services
• you want the drafted re-auth loop, not just a Graphite spike

I’m testing that thin loop as ReAuthWatch (free concierge pilot while validating): https://reauthwatch-canary.netlify.app

Curious how others catch this today — invalid_grant volume alerts, Connected App usage dashboards, or still CS tickets?

What actually breaks

Expiry dates alone are not enough:

• Revocation / rotation can kill a refresh token before expires_at
• Idle TTL / policy changes (Connected App, workspace admin flips) don’t always show up in your app logs as “auth”
• Per-tenant connections fail independently — one customer can be dark while your global “OAuth health” looks green

If you only monitor HTTP 5xx on your API, you will miss this.

A thin canary pattern (no token custody)

You don’t need a full unified-API platform. A useful v1 is boring:

1. Store connection metadata only (provider, tenant id, refresh_token_expires_at, last successful refresh timestamp, last error class)