The Video That Passed Every Check and Failed at Facebook
Every check we ran on the video passed. Correct file, correct duration, correct upload response, correct scheduled status in the tool that was going to publish it. It still did not publish, and nothing in our tooling ever told us why, because nothing in our tooling had access to the reason.
What actually happened
We schedule short vertical videos through a third-party platform that posts to several channels, Facebook Reels among them. The platform re-encodes every video it receives, regardless of the resolution it was uploaded at, to a fixed output of 406 by 720 pixels.
Facebook Reels has two separate requirements: a resolution floor of 540 by 960, and an aspect ratio that must be exactly 9:16.
406 by 720 fails both, in two different ways that happen to point in the same direction. As a ratio, 406:720 works out to 0.5639. Exactly 9:16 is 0.5625. That is close enough to look right and far enough to be rejected. And separately, at a height of 720, an exact 9:16 frame would need to be 405 pixels wide — so the platform’s fixed output is also one pixel wider than the frame it is claiming to produce. Two failures, same file, same cause: the platform picked an output size that satisfies neither constraint Facebook actually enforces.
Why nothing told us
This is the part that made it expensive rather than merely wrong. Facebook does not reject the video outright, with an error a monitoring system could catch. It accepts the post, and then, at the moment it would otherwise publish, it fails silently on its own side of the integration.
From inside the scheduling platform, the sequence looks like this: a post is created, uploaded, and shows a scheduled status. Nothing about the create or upload response indicates a problem. Then, at or after the scheduled time, the status reverts to draft and the scheduled flag clears — with no error field populated anywhere we could find. The platform does not say “Facebook rejected this.” It just stops being scheduled, as if nobody had ever asked it to be.
If you are watching for an error, there is not one. If you are watching for the post to go live, its absence looks identical to a delay, a queue backlog, or any of a dozen benign explanations. We lost real time to each of those explanations before finding the actual one.
The signature that gave it away
The pattern that let us diagnose it, once we started looking properly: the timestamp when the post’s record was last modified lands within about ten seconds after the timestamp it was scheduled for.
That gap is too short to be a person editing the post, and it is a strange thing for a queue delay to produce — a delay would push the modification later and more irregularly, not cluster it within ten seconds of the original schedule. A ten-second gap, consistently, right at the scheduled moment, is what the platform’s own silent-revert logic looks like from the outside: it tries to publish, fails against Facebook’s constraints, and immediately writes the reverted status back, all within the same short window.
Once we knew to look for that gap specifically, we could distinguish “this genuinely has not been attempted yet” from “this was attempted and failed invisibly” without needing any error message at all, because the platform was never going to give us one.
The fix
We stopped publishing these videos as Reels. The scheduling platform also supports publishing a video as a normal post rather than through the reel-specific pathway, and a normal post does not carry the 540x960 floor or the exact 9:16 requirement that Reels enforces. The same re-encoded 406x720 file that Facebook silently rejected as a Reel is acceptable as an ordinary video post.
We proved this rather than assumed it. Three posts that had previously failed as Reels were rescheduled as ordinary posts, using the identical media file, and all three published successfully on 18 September. Same video, same platform, same account — the only variable that changed was which publishing pathway we asked the platform to use, and that was the entire difference between silent failure and success.
What this means past one platform
The general shape here is worth separating from Facebook and from video specifically, because it recurs anywhere your business depends on a tool that sits between you and a platform with its own rules.
A tool that re-encodes your media to a fixed output has effectively decided which of the destination platform’s rules you can satisfy, and it may not have checked. The re-encoding step exists for good reasons — consistency, file size, compatibility — but a fixed output size is only correct for the specific requirements of whichever destination the tool’s authors tested against. Ours was tuned for somewhere that was not Facebook Reels, or was tuned once and never revisited as Facebook’s own requirements changed.
Accepted is not published, and your monitoring needs to know the difference. A status of “scheduled” that later becomes “draft” with no explanation is not neutral information — it is the platform telling you something failed, in the only vocabulary it has available, which in this case was silence rather than words. If your dashboards only alert on explicit errors, a failure mode like this one will never trigger anything.
A timing signature can substitute for an error message when no error message exists. We did not get a “Facebook rejected this” flag. We got a pattern in when records changed, and that pattern was diagnostic once we knew to look at it as data rather than noise.
If your business runs any automated posting, uploading, or publishing pipeline through a third-party tool, the two questions worth asking are what that tool actually re-encodes your files to, independent of what you upload — and whether “scheduled” reverting to “draft” would ever reach a person, or would just sit there looking like nothing happened. We build that kind of monitoring into the managed IT support we run for clients, specifically because platform-side silent failures do not announce themselves.
This is the same family of problem we wrote up in six failures that each exited zero, where one of the six was a hosting service returning a valid-looking URL for a video that had not finished processing. And it is the reason we built an explicit publish boundary around every outward call our own pipeline makes — irreversible actions need a wall, not a flag, and a status field you cannot fully trust is exactly the case a wall is for. We have also written about the opposite failure — a check reporting a phantom problem — because telling the two apart, a real platform rejection from a broken check, is the same skill applied in both directions.
Ash Ganda is the founder of Cloud Geeks, which provides managed IT support and cyber security for Australian small and medium businesses.