Why scheduled social media posts fail, and how to prevent it
The six reasons a scheduled post does not go out, how to tell them apart, which ones fix themselves, and a 10-minute weekly check.
The launch post was scheduled for 9 a.m. At 11, someone from sales asks why it is not on LinkedIn. That is often how a failed post gets found: late, and by someone else.
When a scheduled post does not go out, check six possible causes. Rule out two first: the network's access to your account expired, or the network refused the content. The other four are a refused account, a plan limit, a temporary problem on the network, and a send nobody can confirm. Some need a person; some fix themselves.
How a scheduled post travels
A post scheduled to five networks is not sent once. At the scheduled time, the scheduler sends a separate request to each network, with that channel's own text, media and access, and each network answers on its own. So one post can publish on four channels and fail on the fifth. Publedia shows that as Partially failed, with one row per channel. When you go looking for the problem, look for the one channel that failed and its reason.
1. Access expired or was withdrawn
When you connect an account, the network gives the scheduler permission to publish for you. That permission can end in several ways:
- On a fixed schedule. LinkedIn issues every access token with a 60-day lifespan, so a LinkedIn channel needs a new sign-in about every two months, even if nothing else changes.
- After a password or security change, which can end the access a network gave to connected apps.
- When someone removes the app in the network's list of connected apps.
- When you lose your role on a Facebook Page.
The giveaway is that every post to that channel fails, and the reason points at authorization rather than the content. Reconnect (sign in again as the same account), then retry the posts that failed. Scheduled posts are kept while a channel is disconnected.
In Publedia, a channel with a fixed expiry shows Expiring soon in the 7 days before it lapses and Expired after; access the network withdrew shows Needs reconnection. Once a channel stops working, workspace members get an email. Before that, the status on Channels is the only warning, which is why the weekly check below starts there.
2. The network refused the content
The network received the post and said no. Typical reasons:
- The text is over the limit, or the network counts it differently from your editor. X counts weighted characters (emoji and Chinese, Japanese or Korean characters count as two, every link as 23), and Bluesky counts graphemes.
- Too many images for that network.
- A file type the network does not accept.
- A video longer than the channel allows, such as anything over 10 minutes on TikTok.
- A format the channel does not take. Through Publedia, Instagram needs an image or a video, TikTok and YouTube take video only, and Bluesky takes no video.
- Content that the network's rules block.
The sign is that one post fails on one channel while other posts to the same channel go out fine. Edit that channel's version and retry; sending it unchanged gets the same answer. Better to catch it before scheduling: Publedia checks every channel's version against its network's limits before the post can be scheduled, and says what to change. The social media character limits guide lists each network's ceilings and how it counts.
3. The network refused the account
Sometimes the access and the post are fine, but the network will not let this account publish. The account may be restricted or suspended, or you may no longer manage the Facebook Page. Publedia shows this as Not permitted.
Retrying changes nothing until the account is sorted out. Fix it on the network first, then retry.
4. A plan or allowance limit
This one is the scheduler's own limit, not the network's. In Publedia, posts to X count against a monthly X allowance, which is checked again at the moment a post is sent. A post scheduled early in the month can find the allowance used up by the time it is due. It never reaches X and shows Plan limit reached.
Either wait for the allowance to reset on the first of the month (UTC) and retry, or change plan in Settings, Plan and usage. A workspace that connects its own X developer app is not limited by the allowance; X charges for that app's posts directly.
5. A temporary problem on the network
Networks rate-limit busy apps, stop answering and go down. The post was fine; the network could not take it right then. These show as Rate limited, Platform unavailable or Timed out.
These usually clear up on their own. Publedia retries them automatically, up to five attempts in all, waiting longer before each one (as long as the network asks, up to 15 minutes). The exception is a timeout that may already have published the post, covered next. The post can read as failed while a retry waits. Email about a failed post goes out only when the automatic retries will not fix it, and failures that happen together arrive as one email, so an outage does not fill your inbox.
6. A send nobody can confirm
The awkward case is a timeout on the way out. The request left, the network did not answer in time, and nobody can tell from the outside whether the post went live. Sending again could publish it twice.
Some networks accept a request identity that lets them ignore a repeat of the same send, and Publedia's automatic retries reuse it for that reason. X, LinkedIn, YouTube and Bluesky do not accept one. On those four, when Publedia cannot confirm whether a send went out, it does not resend on its own; the post says so and asks you to check.
On any network, after a timeout, open the account on the network and look before you press Retry. A retry you start is a new attempt.
Symptoms, causes and fixes
| What you see | Likely cause | What to do |
|---|---|---|
| Every post to one channel fails; the channel shows Expired or Needs reconnection | Access expired or withdrawn | Reconnect, then retry |
| One post fails on one channel while others to it publish | The network refused the content | Edit that channel's version, then retry |
| "Not permitted" although the channel is connected | The network refused the account | Fix the account on the network, then retry |
| X posts fail with "Plan limit reached" | Monthly X allowance used up | Wait for the reset, or change plan |
| "Rate limited", "Platform unavailable", or "Timed out" with no other message | Temporary problem on the network | Usually nothing; automatic retries handle it |
| "Couldn't confirm whether this post went out" | Uncertain send after a timeout | Check the network; retry only if the post is missing |
For the steps in the product, see fix a post that failed.
A 10-minute weekly check
Once a week, before the next week's posts go out:
- Open Channels and look for anything that is not Connected. Reconnect what needs it.
- Look past the 7-day warning for big days. If a LinkedIn channel was connected close to 60 days before a launch, reconnect it now. For client accounts, ask a week ahead when the reconnect needs their sign-in. See reconnecting a channel.
- Open next week's posts and read each channel's preview and counter, X and Bluesky especially.
- Check video lengths against each channel's limit.
- If next week is busy on X, check the allowance in Settings, Plan and usage.
What to look for in a scheduling tool
Ask these questions of any tool, including the one you use now:
- Does it report the result per channel, with the reason in plain words and a next step?
- Does it warn you before access expires, and tell the team when a channel stops working?
- Does retry resend only to the channels that failed, so the ones that published are not posted to again?
- After a timeout it cannot confirm, does it resend blindly or stop and ask?
- Does it check each network's limits before you schedule, so a refusal shows up while you are writing rather than at 9 a.m.?
In Publedia, each post has one row per channel with what happened, why, and the one step most likely to fix it. See how that fits the work of social media managers.
Sources
Topics
- Publishing
- Troubleshooting
- Reliability

