One account-security change invalidated the Meta login, and every Facebook page and Instagram account disconnected at once

access_denied: Permissions error
The session has been invalidated

# The Day Four Pages Stopped Talking to Facebook

On 2026-10-19 everything connected to one owner's Meta login stopped working at once. The app was fine. Our servers were fine. The thing that broke lived entirely on Meta's side of the fence, and it took a while to see that, because nothing about it looked like a Meta problem at first.

So here's the post-mortem. Plainly, the way I'd tell it to another engineer over a coffee.

Symptom

Every connected Facebook page token started failing with HTTP 401, error codes 190 and 460, and the message was always the same: "The session has been invalidated". Four Facebook pages dropped in one go. Not one, then another, then another. All four, together.

Instagram was different. The profiles went down one by one, and the reason only made sense later: their tokens fail when they try to refresh, so each one waits for its own turn to die. If you were watching a dashboard you'd see a slow trickle of Instagram failures behind the sudden Facebook cliff, and you'd be forgiven for thinking two separate things were going wrong.

Then came the strange part. I tried the reconnect link. It failed in about three seconds, and crucially it failed before any permission dialog appeared. No screen asking what the app could access. Just a bounce straight back with access_denied: Permissions error.

That detail bothered me more than anything else. A permissions error that fires before you've been shown any permissions? That's not a user declining something. That's something being refused at the door.

What we thought it was

I assumed the app had lost its standing with Meta. Hear me out, because it's a believable theory.

An access_denied with the words "Permissions error" reads like an app-level problem, you know, a revoked permission or a scope that got pulled, maybe a review that lapsed. Those things happen, and when they do, every connection tied to the app fails together, which is exactly what four pages dropping at once looked like. The instant failure fit too. If the app itself were blocked, you'd expect Meta to refuse it immediately rather than walk anyone through a dialog first.

So I went looking at the app. Its status, its permissions, its configuration. And it was healthy. Absolutely nothing wrong with it. That was the moment the theory should have died, but I'll be honest, I spent a bit longer than I'd like to admit trying to make a healthy app look guilty. You do that sometimes. The error message is pointing at permissions, so you keep staring at permissions.

The thing I'd missed was that the error was describing the wrong party. It said permissions, but the problem wasn't what the app was allowed to do. It was who was asking.

Root cause

Here's the actual chain, start to finish.

A change was made to the sign-in security on the owner's Meta login. Meta responded by invalidating the session tied to that login. Every Facebook page token we held had been issued under that session, so when the session went, all of them went with it. That's the 401 with codes 190 and 460, and "The session has been invalidated" is Meta telling you precisely that, in words I'd skimmed past because I was busy looking at the app.

Instagram followed because of how its tokens work. They don't fail the instant the session dies; they fail when they next try to refresh and discover there's nothing valid left to refresh against. Hence the staggered pattern.

And the instant access_denied: Permissions error on reconnect? That was the login itself still carrying a pending security step. Meta wouldn't let the authorisation flow begin until that step was finished, so it refused before showing any dialog. The app was never the issue. The account had unfinished business, and the refusal just happened to be worded as a permissions problem.

Once the pending security step was completed, the reconnect error cleared. No code change on our side was needed to make that part work.

The fix

There were two halves, and only one of them was clever.

The unclever half was the recovery itself. Complete the pending security step on the login, then reconnect. But "reconnect" isn't one action. Each of the four Facebook pages needed its own reconnect, and each Instagram profile needed its own too. There's no single button that restores the lot, because each connection holds its own token and each token had to be re-issued individually.

The second half concerned the posts. Anything that failed to publish while a connection was down got marked ambiguous rather than simply failed. That's deliberate. If a post errors out while disconnected, we can't know whether it actually reached the platform before the failure, and silently retrying risks publishing something twice. So those posts sat waiting until someone gave an explicit approval to retry. It's slower, yes. But a duplicated post on a public page is harder to undo than a delayed one.

Why it happened

This is the part worth dwelling on, because the failure itself was ordinary and the survival of our blind spot wasn't.

Our handling treated token failure as a property of the connection. Something went wrong with this page, so mark this page as broken. That model is fine when failures are independent. It falls apart when one upstream event invalidates everything at once, because nothing in the design asked whether four simultaneous failures might share a single cause.

And the error wording nudged us the wrong way. A permissions message sent attention to the app, so review of the failure path never had to confront the idea that the account, not the app, could be the thing refusing. It passed because every individual piece behaved sensibly. The gap was between the pieces.

How to avoid it

If you integrate with any platform that issues tokens under a user session, a few things carry over.

First, correlate failures before you diagnose them. Several tokens dying together is evidence of a shared parent, so look upward before looking at each child. Second, treat a refusal that arrives before any user-facing step as a statement about the account or session, not about permissions. Third, tell your users plainly that security changes on a connected login can sever every connection beneath it, and that recovery may need a step on the platform's side first.

Finally, make ambiguous outcomes explicit rather than guessing. A post you aren't sure about deserves a human decision, not a quiet retry.

That's really all of it. Healthy app, invalidated session, one unfinished security step. I looked at the app far too long.