I'm noticing that our customer connected accounts appear to be expiring often, much more often than they used to. Always possible something in our stack is misrepresenting the state, but wanted to check to see if other people are experiencing this/reporting this as a repercussion from the breach

Hey Peter, not really, would you mind sharing a few connection IDs for us to look into?

I'll see if I can track some down. Part of this issue was actually connections being in the status

REVOKED

but nothing telling our system. We use the webhook for expired connection notifications. Any chance you guys are planning to add a revoked webhook alert as well? Or even a general "status changed" webhook

We mass-revoked connections during the incident. Apart from that, we didn't revoke any - it can only be done by Org members. > Any chance you guys are planning to add a revoked webhook alert as well? Or even a general "status changed" webhook I'll log this as a feature request for our product team to review

another example - a connection I initiated just a few days ago just came in as expired: connected account id: ca_G7chHBmBMlU6 "created_at":"2026-06-16T13:54:20.252Z" "updated_at":"2026-06-18T21:15:01.075Z" "status_reason":"Permanent auth error during token refresh" We got a connection expired webhook letting us know: [2026-06-18T21:15:01.664Z] [container:bb79dfd6] [route:ComposioWebhook] INFO: [INVALID_CONNECTED_ACCOUNT] Composio webhook reported connection expired reason - webhook_expired previousState - ACTIVE connectedAt - 2026-06-16T13:54:43.129Z organizationId - 38678a97-e513-42cd-a262-9b7202d78ce6 integrationSlug - sentry connectedAccountId - ca_G7chHBmBMlU6 connectionId - 33971a44-860f-4162-b47a-379eb6d1733c connectionAgeDays - 2

Hey, sorry for the issue. Looking into it and will get back in an hr with updates

Appreciate the update. I'll reconnect sentry

Hey Peter, checked the other connection IDs as well. These were not Sentry:

ca_T28L725zFm2v

was Google Super,

ca_4vc_ZVZcEUwl

was Gmail, and

ca_l4YJZRHTHMoX

was Outlook. All three ended up as

EXPIRED

due to permanent auth failure during token refresh, not

REVOKED

. For the Google Super example, Google returned

invalid_grant

, which means the refresh token was no longer valid. The older Gmail/Outlook examples show the same permanent refresh-failure class on our side. This usually happens when the provider invalidates the refresh token. Common causes are: • The user revoked the app's access. • The user changed their Google/Outlook password, enabled 2-Step Verification/MFA, or otherwise changed account security settings. • A Google Workspace / Microsoft admin changed security, session-control, or conditional-access policies. • For Google specifically, each user can hold roughly 50 live refresh tokens per OAuth client; creating the 51st connection can invalidate the oldest refresh token. • Some Google Workspace domains enforce periodic token/session revocation. Once the provider rejects the refresh token this way, retrying from our side cannot recover the old token. The affected accounts need to be reconnected; after reconnecting they should work normally unless the same provider/user/admin policy invalidates the new refresh token again.

Thank you for the info. I'll continue to search for examples that are out of the ordinary and will report any here. Appreciate your follow through

Checking

ok, so clearly their end again. Appreciate you

We're also getting reports of dropped connections fairly frequently from our customer base

hey, could you please share the connectionIds? Feel free to email support@composio.dev with more details

Thanks Abishek, i'll drop an email now

Hey @Peter Keens, quick update after going through the Sentry thread and the connection-expiry examples. On the Sentry side, we heard back from their support team. Their logs showed the refresh request from Composio did reach Sentry, and they wrote the new token on their side, but their backend returned a

500

before Composio received a usable refresh response. The sharp edge here is Sentry's refresh behavior: once a refresh attempt generates a new token, the older access + refresh tokens are immediately invalidated. Unlike some other providers, there doesn't seem to be a grace window where the old refresh token can still be retried. So if Sentry returns a

500

after generating the new token, the old refresh token is already dead, and any follow-up refresh attempt will fail with

401

/ invalid token. At that point the connection has to be reconnected. Immediate mitigation from our side: we've changed the Sentry refresh cadence to refresh much later in the token lifetime instead of refreshing aggressively. That should reduce the chances of hitting Sentry's intermittent

500

path and should make short-lived Sentry expirations much less likely. Sentry also recommended using their client credentials flow as a more resilient path for integrators. We've added support for that to our roadmap, and we're keeping the Sentry support thread open for their RCA / fix path.

Appreciate your updates, Abhishek!

Hi Peter, I dug into this Notion case. This connection is using the Composio-managed Notion OAuth app, not a custom OAuth app. Apart from a user/admin explicitly removing the Notion integration from the workspace, the most common Notion OAuth expiry path we see is reauthorization of the same Notion user against the same OAuth app. Notion rotates refresh tokens, so when the same user connects again through the same app, Notion can issue a new access/refresh token pair and invalidate the older refresh token. The older connection may keep working for a short time, then expire once the access token needs to refresh. We document that here: https://docs.composio.dev/toolkits/notion#reasons-for-notion-connection-expiry For production, I strongly recommend using your own Notion OAuth app instead of the Composio-managed/default app, and keeping one active Notion connection per real user/app. That gives you better isolation and reduces the chance of reconnects invalidating older connections unexpectedly.

Appreciate the info, I'll pass thing along