When a social API reports success and nothing happened
A social API reporting success is not evidence that the operation happened. These are five cases we measured on a publisher running across nine networks, each one already costing us something before we found it.
Two are the network returning a success for something that did not happen. Two are our own instrumentation being structurally unable to show a total failure, which is our fault and the more useful half. One is data that genuinely does not exist, which is nobody’s fault and still sends you chasing a bug that is not there.
Every figure below carries the date it was measured and links to the page where we first published it, so you can check the claim rather than trust it.
By Tayyab, Founder · Published
Facebook and Instagram accept a first comment, then drop it
The network reported a success · measured 18 August 2026
We probed a first comment end to end on every network our publisher supports, because the integration documentation says Facebook and Instagram accept one. They accept it and then drop it. The root post publishes, the comment container comes back empty, and no error is raised anywhere in the chain.
That is worse for us than it sounds. We strip the link out of the post body before publishing, so a comment that silently never arrives does not merely fail to help: it destroys the link. The same probe confirmed LinkedIn delivers with a real comment id returned, and that X delivers and chains across three or more containers.
What changed: We treat a first comment on those two networks as best effort rather than a place to put anything the post depends on.
First published on /features/first-commentFive of six publishes marked stuck had already gone out
The network reported a success · measured 24 August 2026
The obvious reading of a publish stuck in flight is that it never happened. We checked six rows carrying the wedged-publish error: five were already live on the platform, each with a publish timestamp recorded by the network itself.
Marking those failed would have invited a retry, and a retry posts the same thing to a real audience twice. A duplicate post is not something you can take back, which makes the safe-looking default the dangerous one.
What changed: The reaper now asks the platform what actually happened before it decides, and a row it cannot resolve stays unresolved rather than being guessed either way.
First published on /features/auto-publishingOne network was completely dead and 155 runs reported success
Our own metric could not show it · measured 24 August 2026
Six Threads posts probed directly returned six 500s, against an Instagram control that answered 200. Eighteen Threads posts sat inside the sync window, so roughly a fifth of every tick’s budget was being spent on work that could not succeed, and had been for days.
Across the 155 runs on record at that point there were 898 failures against 3,130 processed, and all 155 reported success. A pooled failure rate cannot show one network being completely dead: the other networks carry the average, and the run record stays green while a fifth of the budget burns.
What changed: We did not fix it by calling a 500 permanent, because a 500 is plausibly transient and reclassifying a vendor outage as permanent is how a post gets abandoned. The rate is now read per network.
First published on /features/comments-inboxA counter that reads its own budget cannot show a backlog
Our own metric could not show it · measured 106 recorded runs
Every run reported 50 posts considered, because 50 was the API budget. It read exactly 50 on all 106 recorded runs while 188 published posts sat waiting and were never captured once.
The selection ranked candidates by publish date, which only ever falls as you publish more, so a post that dropped below the cut-off could never come back into the candidate set no matter how many ticks ran. A capped number cannot tell a drained queue from a starving one, so the one figure that would have shown it was the one figure that could not.
What changed: Selection is ordered by how stale a post’s capture is rather than how recently it published, and every tick records the uncapped count of what was still due.
First published on /features/post-analyticsThe pattern, and the two rules we took from it
These have one thing in common. In each, a status was available and it was wrong: the run record said success while a network was dead, the counter said 50 while 188 posts waited, the publish row said in flight while the post was already live. None of them was hidden because it was subtle. Each was hidden because the thing we were watching could not have shown it.
- A metric that can hit a ceiling must also record the uncapped number. Otherwise it reports the ceiling forever, and the ceiling looks exactly like a healthy queue.
- A success rate pooled across networks cannot show one network at zero. The healthy ones carry the average. Break it down per network or it will hide precisely the failure you care about.
Related measurement
The limits our publisher enforces across nine networks, including the two places a network counts differently from how it documents it, are in social media API publishing limits. That page carries the publish that stayed wedged for 52 days, which is the incident this one grew out of.
Frequently asked questions
Can a social media API return success for a post that never appeared?
Yes, and we have two measured cases. Facebook and Instagram accept a first comment, publish the root post, return the comment container empty, and raise no error anywhere in the chain. Separately, of six publishes our own system had marked as stuck in flight, five were already live on the platform with a publish timestamp recorded by the network. In both directions the status you get back is not the state of the world.
Why did our monitoring not catch a network being completely down?
Because the failure rate was pooled across networks. On 24 August 2026, six Threads posts probed directly returned six 500s against an Instagram control that answered 200. Across the 155 runs on record at that point there were 898 failures against 3,130 processed, and all 155 runs reported success. A pooled rate cannot show one network sitting at zero, so the dashboard was green for days.
Why does a capped counter hide a backlog?
Because it reports the cap rather than the work. Our analytics tick considered 50 posts because 50 was the API budget, so it read exactly 50 on all 106 recorded runs while 188 published posts sat waiting and were never captured once. A number that can only ever reach its own ceiling cannot tell a drained queue from a starving one. Every tick now also records the uncapped count of what was still due.
Why do Instagram comments have no author name?
Because the field is not there to fetch. Probed against the live API on 23 August 2026, the integration returns an empty author field for every Instagram comment, and for LinkedIn a bare actor URN with no endpoint anywhere that resolves it to a name. Nothing is broken and no retry will help, so we label the person by network rather than showing "Unknown account" and letting you conclude the sync failed.
What should I check in my own publishing pipeline?
Two things, both learned the expensive way. Any metric that can hit a ceiling must also record the uncapped number, or it will report the ceiling forever. And any success rate pooled across several networks must be broken down per network, because a pooled rate structurally cannot show the one failure you most need to see.
Instagram comments carry no author, and that is not a bug
The data is not obtainable · measured 23 August 2026
Probed against the live API, the integration returns an empty author field for every Instagram comment, and for LinkedIn a bare actor URN with no endpoint anywhere that resolves it to a name.
This one is nobody’s failure, which is why it belongs here. The name is not missing because something broke, it is genuinely not obtainable, so every retry and every bug report chasing it is wasted work.
What changed: We label the person by network, "Instagram user", rather than showing "Unknown account" and letting you conclude the sync failed.
First published on /features/comments-inbox