Why do my social accounts keep disconnecting?
The single most common complaint about every social publishing tool, explained: what actually expires a connection, and how to tell a real disconnect from a false alarm.
By André LugBecause every publishing tool sits on OAuth credentials it doesn't fully control. Disconnects come from a few external events: token expiry, the customer revoking access in the platform's own settings, a platform-forced re-authorization, or page and permission changes that silently invalidate a token. What varies between tools is whether they can tell a real disconnect from a false alarm — and say which one happened.
Ask anyone who manages social accounts through a third-party tool what frustrates them most, and "my accounts keep disconnecting" comes up before anything else — before pricing, before missing features, before UI complaints. It is the single most common complaint about every social publishing tool on the market, including PostGate.
That is not because disconnects are rare or avoidable. Every publishing tool sits on top of OAuth credentials it does not fully control, issued by platforms that revoke, expire, and re-scope access on their own schedule. The difference between a well-built integration and a bad one is not whether disconnects happen — it is whether the tool can tell a real disconnect from a false alarm, and whether it tells the customer clearly which one just happened.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
What are the real technical causes?
A "disconnected" account is almost never PostGate, or any publishing tool, arbitrarily dropping a connection. It is one of a small number of specific, external events:
- Token expiry. Access tokens have a lifespan set by the platform. A short-lived token that is never exchanged for a long-lived one, or a refresh that silently stops happening, eventually just runs out.
- The customer revoking access from the platform's own settings. Someone cleans up their connected-apps list on Instagram or LinkedIn, forgets which tool the entry belonged to, and removes it. From the platform's side this is indistinguishable from any other revocation.
- A platform-side re-authorization requirement. Providers periodically force a fresh login for security reasons, after a password change, or after a permissions model migration — independent of whether the existing token was technically still valid.
- Page, business, or permission changes on the platform. An Instagram account gets detached from its linked Facebook Page, a team member loses admin rights on a Page the token depended on, or a granted scope is deprecated — any of which can silently invalidate what looked like a healthy connection.
Every one of these originates outside the publishing tool. A tool that is publishing reliably one day and blocked the next has not necessarily done anything wrong — but it does need to know immediately which of these four things happened, because the fix and the message to the customer are different for each.
How do you tell a real disconnect from a false alarm?
A false alarm is a transient blip that self-resolves: a slow provider response mistaken for a dead token, a rate limit misread as a revocation, a momentary network failure during a scheduled refresh. A real disconnect is a state that will not resolve itself no matter how many times you retry, because the credential is genuinely gone.
The only reliable way to tell them apart is to check connection health directly, rather than inferring it from a single failed publish attempt. PostGate's profile health endpoint returns the current status, the scopes actually granted, token expiry, and an explicit reconnect_required flag — so a client can distinguish "this call happened to fail" from "this profile is authoritatively broken and needs the customer."
curl https://api.postgate.studio/api/profiles/pro_instagram123/health \
-H "Authorization: Bearer $POSTGATE_API_KEY"
{
"status": "active",
"granted_scopes": ["instagram_content_publish", "pages_show_list"],
"token_expires_at": "2026-09-10T00:00:00.000Z",
"reconnect_required": false
}What minimizes false disconnects?
A well-built integration refreshes tokens proactively, before they expire, rather than waiting for a publish call to fail and reacting after the fact. It treats a single transient error as exactly that — retryable — instead of immediately flipping a profile to a broken state on the first failed request. And it separates "about to expire" from "already broken," so a customer sees a heads-up while there is still time to act, not a surprise outage.
PostGate fires profile.expiring when an authorization is nearing expiry, giving the customer a window to reconnect before anything actually breaks. It fires profile.expired only when a token has run out with no way to refresh it, and profile.reauth_required only when the provider itself rejected a refresh or a publish attempt — carrying a specific reason of refresh_failed, revoked, or publish_auth_error, so the message shown to the customer can name the actual cause instead of a generic "something went wrong."
How should real disconnects be communicated?
Both profile.expired and profile.reauth_required fire once per authorization state transition, not on every background maintenance sweep — so a customer's inbox does not fill up with repeated alerts about the same broken connection, and a profile that reconnects and later breaks again correctly fires a fresh event rather than staying silent.
That combination — proactive expiry warnings, a specific reason on every real break, and no duplicate noise — is what separates a tool customers trust from one where every disconnect alert gets ignored because the last five were false alarms.
Frequently asked questions
How can I tell if a social account is really disconnected or just having a transient error?
Check connection health directly instead of inferring it from one failed publish. A false alarm is a transient blip that self-resolves — a slow provider response, a rate limit misread as a revocation. A real disconnect never resolves by retrying because the credential is gone. PostGate's profile health endpoint returns current status, granted scopes, token expiry, and an explicit reconnect_required flag.
Can a publishing tool prevent social accounts from disconnecting?
No — every cause originates outside the tool: token expiry, revocation from the platform's own settings, forced re-authorization, or page and permission changes. What a well-built integration can do is minimize false disconnects: refresh tokens proactively before they expire, treat a single transient error as retryable instead of flipping the profile to broken, and separate "about to expire" from "already broken".
How does PostGate warn me before a connection actually breaks?
PostGate fires profile.expiring when an authorization is nearing expiry, giving the customer a window to reconnect before anything breaks. profile.expired fires only when a token has run out with no way to refresh it, and profile.reauth_required only when the provider itself rejected a refresh or publish — carrying a specific reason of refresh_failed, revoked, or publish_auth_error.
Will I get repeated alerts about the same broken connection?
No — profile.expired and profile.reauth_required fire once per authorization state transition, not on every background maintenance sweep. A customer's inbox doesn't fill with duplicate alerts about the same break, and a profile that reconnects and later breaks again correctly fires a fresh event rather than staying silent.
