What happens when a platform rejects a post
Every failed post in NioConnect carries exactly one reason from a closed list, and one next step. Here is the list, in plain words, and what each reason asks of you.
The NioConnect team5 min readOn this page
A reason, not a shrug
When a post fails, the useful question is not that it failed but what to do about it. A tool that only says failed leaves you to guess whether to retry, rewrite, reconnect or pay.
NioConnect sorts every terminal failure into one reason from a fixed list. Because the list is closed, each reason can be tied to one remedy, and the calendar can show the remedy next to the post. The list is also the reason we can promise that nothing fails without a cause attached.
The states a post moves through
A post is a draft, then queued, then publishing, and ends as published or as failed. A post you cancel ends there too. Published is only written once the platform has confirmed the post, so a failure never hides behind a green tick. The state on the calendar is the same state the system acts on, so what you read is what actually happened.
The reasons, and what to do about each
There are ten reasons. They fall into four kinds: about the channel, about the content, about the platform and about the account. The table lists them with the one thing each asks of you.
| Kind | What happened | What to do |
|---|---|---|
| Channel | The saved access had expired or been revoked | An Owner or Admin reconnects the channel, then retries |
| Channel | The channel was switched off | Turn it back on, then retry |
| Channel | The channel was disconnected | Connect the account again, then schedule the post to it |
| Content | The platform would not accept the post as written | Edit it for that platform and schedule it again |
| Content | The media could not be prepared for the channel | Replace the file and schedule again |
| Platform | The platform refused the post or could not take it just then | Retry sends it again to the channels that failed |
| Platform | The platform asked us to slow down | Nothing: the post waits its turn and goes out on its own |
| Account | The workspace is over its plan limit for the period | An Owner can change the plan |
| Account | A payment failed and the grace period ended | An Owner puts the subscription back in good standing |
| Ours | Something went wrong on our side | The post is held rather than published incomplete; retry sends it again |
What gets retried for you, and what does not
Only errors that can succeed later are retried automatically. A platform asking us to slow down is the clearest case: the post is held, not failed, and goes out when the platform allows it. A post that cannot succeed as written is not retried blindly, because retrying content a platform has refused only repeats the refusal. It tells you why, which is the part you can act on.
One reason cannot be cleared by retrying at all. A disconnected channel is a retired connection, and reconnecting makes a new one, so the post has to be scheduled to the new channel. Retrying would only fire the same alerts again.
For some reasons the platform's own words are shown on the post. For others they are not, because showing them would not help you and could expose more than it should. The plain reason is always there.
Held is not failed
Some posts do not go out and are still not failures. A hold keeps the post in its state and lets it publish once the cause is gone, so a temporary condition does not turn into a pile of errors and alerts.
Four holds are worth knowing. An emergency stop pauses every publish path in a workspace, and a post whose time passed during the stop is held rather than published late. A post can be awaiting approval. A downgrade can switch a channel off, which holds its posts until the channel is restored. And a workspace whose Owner has not yet verified their email holds posts until they do, so nothing reaches a real audience before then.
Who can act on a failure
Remedies follow roles. Reconnecting or switching a channel back on is for an Owner or Admin, because it changes how the workspace is connected. Changing the plan or fixing billing is for an Owner. Editing a post, replacing media and retrying are the everyday actions of the people who write the posts.
The calendar says so in the reason itself, naming who can do the thing, so a Contributor who sees a failure knows to ask rather than to hunt for a button that is not theirs.
Retries that do not double post
Retrying carries its own risk: the second attempt could post a duplicate if the first actually landed. Each publish attempt carries a key that exists before the platform is called, and the platform is read back before anything is posted again. That is how a retry stays a retry and does not become a second post.
If you want the longer story, why scheduled posts fail silently covers the quiet failures this design is meant to prevent, and the help article Why a post failed is the short version.
Written by The NioConnect team.
Posts that say why they failed, on one calendar.
Start 7-day trial