Why My Scheduled Posts Failed to Publish (2026)

The three real reasons a scheduled post fails

Every scheduler worth using surfaces failure the same way: a red ring on the calendar entry, with a reason in the tooltip. The Postiz documentation puts it bluntly - the three usual causes, in order of frequency, are a channel that needs reconnecting, a post that broke a platform rule, and content the platform rejected. That ordering tells you where to look first.

Cause 1: The channel needs reconnecting

This is the one that catches people. A channel is not a permanent login - it is OAuth credentials the platform will eventually expire. When that happens, the channel gets a red marker in the sidebar and every post queued against it starts failing. Meta access tokens are the clearest example: short-lived ones last roughly one to two hours, long-lived ones about sixty days, and Meta warns lifetimes may change without notice. TikTok's windows are tighter.

The trap is that the failure is asymmetric. Your other channels keep working, so you see one platform quietly going dark rather than the whole tool breaking. The posts that fail are the ones queued furthest ahead, so you notice the gap weeks later.

The fix is a reconnect, not a re-setup. In Postiz the channel menu offers Reconnect channel, which re-runs authorisation for an existing channel. Reconnecting does not count as connecting a new channel, so it does not consume a channel slot. Postiz also separates this from Disable and Delete - disabling keeps history and frees a slot, deleting is permanent and is refused while posts are still attached. One warning from the same documentation: reconnect as the same account, or you create a mismatch between the channel's history and its new identity.

Cause 2: The post broke a platform rule

Every network has its own rules and they disagree about nearly everything. Postiz supports 34 platforms, and character limits alone range from 300 on Threads and Pinterest to 100,000 on Medium and WordPress. X is the special case - 280 characters normally, 4,000 if verified, 100,000 in article mode.

Media rules are where scheduled posts fail most often, because the mistake is made once and repeated across a queue:

• X takes up to 4 images or 1 video - not both.
• Instagram accepts JPEG only. Other formats fail at the provider even if they upload cleanly on your side.
• Instagram publishing rate limit: 100 API-published posts per rolling 24 hours, with a carousel counting as one post.
• Facebook Pages allow roughly 63,000 characters; Slack around 400,000; Discord about 1,980.

Required settings are the silent blockers. In the Postiz API each post carries a settings object with a __type field identifying the platform, and several platforms demand specific options - X accepts who_can_reply_post values like community, and a missing or invalid value is a rejection rather than a default. Instagram additionally requires a professional account, and Meta's docs require Page Publishing Authorization in some configurations.

That last option - "draft" - is worth using as a safety net. It lets you stage the payload through an automated workflow and inspect it in the composer before committing it to a publish time.

Cause 3: The platform rejected the content

Some failures are not about your scheduler at all. The platform looked at the content and said no: duplicate text, a blocked link, or an account restriction. The platform's error message is the whole diagnosis - read it verbatim.

Duplicate text deserves attention because it is the least intuitive. Pushing the same caption to several networks in the same short window can trip platform duplication filters - the opposite of what cross-posting tools assume. Recycled evergreen content fares no better: YouTube's policy on inauthentic and repetitious content covers repetitive or mass-produced content at the channel level.

The safe pattern is to vary the copy per platform rather than pushing one identical blob everywhere. Postiz gives each channel its own preview in the composer, so you can adjust copy, media and hashtags first. If you automate it, template the content per socialProvider before it reaches the API.

How to diagnose a failed post in five minutes

Start at the platform, not at the tool. Over the API, step two is a query: listing posts and inspecting each status tells you whether it published, failed, or is still queued.

1. Look for the red marker in the sidebar. If a channel is flagged, the token is the problem. Reconnect it - this alone resolves most failures, in about thirty seconds per channel.
2. Hover the red ring on the calendar entry. The tooltip tells you which of the three causes applies and often includes the platform's own message verbatim.
3. Check the channel against that platform's rules. Character count, image count, file format, required settings. Postiz publishes a per-platform reference covering all 34, including each API __type name - Farcaster is wrapcast, Google My Business is gmb.
4. Rule out rate limits. If a burst of posts failed at once with valid content, look at publishing caps: Instagram's 100 posts per 24 hours, or your scheduler API's request ceiling.
5. Check the transport, if you self-host. A stopped queue worker, full database or bounced Redis strands every queued post at once. That failure has a different signature - every channel fails at once, not one.
6. Reschedule from a saved copy. Failed posts are not replayed automatically, so keep the text and media somewhere you can paste them back.

That same GET /public/v1/posts endpoint is also how you duplicate a post - fetch it, strip the server-managed fields, then resubmit with a fresh type and date.

Three failure modes nobody warns you about

Beyond the three headline causes, a smaller set of problems produces failures that look identical from the outside.

The upload that was too large

Postiz accepts JSON bodies up to 50 MB on the post-creation routes, and you hit that limit almost always by inlining image data instead of uploading first. The error is PayloadTooLargeError. The fix is the two-step flow: upload through /public/v1/upload or /public/v1/upload-from-url, then reference the returned id and path in the post's image array. File limits are separate - 10 MB per image, 1 GB per video. The upload-from-url variant proxies the source URL through the backend, so a slow server or expired signed URL fails it. Videos get a second pass: Postiz inspects duration, dimensions and codec, and unsupported files fail at "Failed to load video metadata". Use MP4 with H.264 video, AAC audio, 30 fps or lower, at or below 1920x1080 - portrait for TikTok and Shorts.

The connect flow that broke halfway

Connecting a channel spans three parties - your browser, the provider and the scheduler backend - so any of them can fail. "Invalid state" means the one-time CSRF token did not match, usually because you started the connect in one tab and finished in another. "invalid_grant" means the authorisation code was rejected: reused by a double-click, expired, or a redirect URI that does not match character for character. "Failed to fetch" is a network-level failure talking to the provider's API. Two known product bugs have no fix on your side either - a TikTok connect page that crashes for some accounts, and an X connect screen throwing t/r is not a function. The workaround for both: start the flow over from the Channels page.

How to stop scheduled posts failing in the first place

Everything above is mitigation. Prevention is cheaper, and comes down to six habits.

• Treat reconnect as routine maintenance. Check the sidebar for red markers on a schedule - weekly for a few channels, daily if you run many.
• Keep a per-platform rules cheat sheet. Limits, image counts, formats and required settings for each network. The most common avoidable failure is a media rule you relearn every month.
• Upload media through the scheduler's own endpoint. Never inline base64 - it keeps you under the body limit and gives reusable id and path.
• Draft first when automating, and keep a copy. Create as a "draft", confirm it renders correctly, then promote it to a scheduled post. Failed posts are not retried, so if content only lives in the scheduler, a reschedule means rebuilding from scratch.
• If you self-host, monitor the queue. A stopped Temporal worker, a full Postgres volume or bounced Redis strands every pending post at once - an unmistakable signature worth an alert.

One more habit if you publish across many networks: watch the API ceiling. The Postiz public API is limited to 90 requests per hour on the create-post endpoint - a fixed value that does not scale with your plan, since plans tier on channels, not throughput. It also does not mean 90 posts per hour, as one request can carry many. Batch rather than loop.

Frequently asked questions

Conclusion: why my scheduled posts failed to publish

To answer directly - why my scheduled posts failed to publish - it is almost certainly one of three things, and the order of likelihood is fixed. An expired channel token comes first, because tokens always expire and most calendars will not tell you when yours did. A platform rule violation comes second, usually a media rule right for one network and wrong for another. Content rejection comes third, and is fastest to diagnose - the error message belongs to the platform.

The difference between a calendar full of red rings and one that just works is not a better tool - it is a reconnect habit, a rules cheat sheet and saved copies of your content. Get those in place and failures shrink to the ones you actually caused, which are the ones you can fix.

If you want a scheduler that shows you the reason for every failure instead of silently dropping posts, try Postiz free and run one post through it. If you would rather self-host the AGPL-3.0 edition, the install guide and full troubleshooting docs are both public.