Key takeaways
- An evening post fired to two social networks from one create. One published on time. The other came back failed, with an error saying the account token had expired and the account needed reconnecting.
- We read that as a dead connection and were about to run a fresh authorisation on somebody's personal account. We were wrong. The platform had already reissued the token, made a second attempt on its own, and published twelve minutes late.
- The platform retries by creating a brand new child post under the same parent. It never flips the failed one. So a failed record stays failed forever and proves a moment, not a state.
- The listing endpoint hides failed children entirely, so the record that would have corrected us was not on the screen we were looking at.
- Our own queue file said posted, because the platform accepted the create. Nothing anywhere in our system records that one network was down for twelve minutes.
A client's social posts go out on a schedule we run. One create, two platforms, one evening slot. The fire log showed it going out at the right minute and nothing after it, which is the script behaving exactly as designed.
Reading the platforms back the next morning, one had published on time. The other had not published at all. Its record read failed, with no publish time, and an error about as unambiguous as errors get: the account token has expired, been revoked, or is otherwise invalid, please reconnect your account.
So we concluded the connection was dead, and that the platform's own account screen saying connected was a stale cached lie.
It was not a lie, and the post went out
Eleven minutes after the failure, the platform had created a second post for that network under the same parent, and published it. Twelve minutes after the slot it was booked for, the post was live.
That retry was not ours. Our fire log shows one fire and zero fires after it, which we checked precisely because a duplicate post is the failure this queue exists to prevent. The platform healed itself, quietly, in the eleven minutes between our two readings.
Both connections read healthy afterwards, with both tokens reissued during the incident window and running two months out. The account screen had been accurate the entire time. What we were reading was a dead child record, and we were inferring the state of a live system from it.
That inference is the actual lesson here, and it is not really about social posting. A true fact about one record, read as a fact about the system. That is the shape of most bad diagnoses.
Why a failed record stays failed
When one platform in a multi-platform post fails, the system does not retry that record. It mints a brand new child under the same parent and tries again with that. The original keeps its failed status and its error message permanently, because nothing will ever go back and update it.
So the only correct way to read a failed post is to look for a newer sibling under the same parent first. A newer one that published means it healed itself. No newer one, and the failure is real and current.
What made that hard is the second half of the problem.
The listing endpoint does not return failed children at all. So it hides the failure, and before the retry lands it does something worse: a post that asked for two networks and managed one comes back looking like a clean single-network post. Nothing in that response says anything went wrong.
The only place the failed status and its error text exist is a direct fetch of the individual record. You have to already suspect something to go and look.
Which gives you the check that actually works. Count the children against the platforms you asked for. If you requested two and the list hands back one, something either failed or is still in flight, and the list will never tell you which.
The blind spot we still have
Our queue file marked that item posted. It was not lying. The platform accepted the create, and accepting a create is genuinely all the queue was ever told.
But it never looked again. For twelve minutes there was one network live, one network down, and a file on our machine reporting success with no error recorded. If the platform had not healed itself, the post would have been half published and nothing anywhere in our system would have said so.
We have not fixed it yet, and the reason is honest rather than flattering. That posting script is shared by six queues, so a change to it touches everything that posts anything. It is written down, and it gets done deliberately rather than mid-incident.
One practical note. When a platform believes an account is healthy, it usually offers no reconnect button at all, only delete. Deleting and re-adding is the sledgehammer, and on a personal account with pages and ad accounts hanging off it that is a genuinely bad afternoon. The real path is the connect button on the posting tool itself, which re-authorises in place without removing anything.
What this means for your business
If you schedule posts, ads, emails or texts through any system, you almost certainly have a version of this. Something accepted your request, told you it worked, and nobody went back to check what the audience actually received.
Accepted is not delivered. Created is not published. Those gaps are usually seconds and occasionally they are twelve minutes, and once in a while they are forever.
The habit worth building costs almost nothing. Once a week, pick one scheduled item that your system says succeeded and go and look at it on the platform it was meant to land on. Not the dashboard. The actual page, the way a customer sees it.
Any marketing automation San Jose business relies on should be readable from the outside. If the only evidence a campaign ran is a green tick in the tool that ran it, you do not have evidence. You have a receipt.
And when something does come back failed, resist the first conclusion. Read one more record before you act, especially when acting means touching authorisations on an account you do not own.
Want this built for you
We build scheduled content systems that get verified on the platform, not in the dashboard, plus the websites and funnels behind them. Start at optechsol.llc.