When a post breaks, you hear about it first.
You cannot watch every account across every brand, client, and location. Publishly checks what went live, explains what did not, and handles temporary problems before they become client calls.
A post is only called successful after Publishly confirms it is live. A failure comes with a clear reason, an alert, and a safe next step. Temporary problems are retried; uncertain outcomes are stopped for review so Publishly never risks posting twice.
Every failure has a name.
These are the actual reasons Publishly uses, pulled from the same list as the posting system. Every failed post gets one reason and one clear next step: Publishly tries again, you take action, or the content needs to change.
Recovers on its own
recoverable · 7 codesA short platform or network problem. Publishly waits, tries again safely, and keeps you informed.
Needs your action
user_action_needed · 7 codesSomething only you can fix — a revoked authorization, a missing permission, a platform restriction. The post is held & the receipt says exactly what to do.
Content problem
data_problem · 6 codesThe platform rejected the content itself. Identical content would fail identically, so nothing retries until you change it.
Every Publishly post failure carries one of 20 documented failure codes in three classes — recoverable, needs-your-action, or a content problem — each with a plain-English default reason.
A receipt for every destination.
Each destination runs as its own tracked delivery with a full state history. A post sent to six chosen brand accounts gets six receipts — one can fail and retry while the other five stay published.
SCHEDULED → QUEUED → PROCESSING → PUBLISHED ↳ RETRYING → PROCESSING ↳ FAILED (class + code + reason)
On success the receipt stores the platform’s post ID & the live URL — proof the post exists, not an inference that it probably does. Poll it whenever you like:
GET /public/v1/posts/:id/status
The failure reaches you first.
A webhook is simply an alert sent straight to your own software. Publishly sends one as a post moves forward and another when it fails. The failure alert includes the reason and whether another safe attempt is coming. This is the actual payload:
Proves the alert came from Publishly
Every alert includes a secure signature and timestamp. Your software can reject a changed, fake, or stale alert before acting on it.
Tries again if your receiver is down
If your alert receiver is temporarily unavailable, Publishly tries three times. The posting result remains recorded even when your endpoint is down.
Keeps a record of every alert attempt
You can see when Publishly called your software, what came back, how long it took, and why an attempt failed.
Publishly signs every alert with HMAC-SHA256, tries delivery up to three times, and records what happened on every attempt.
Retries that can’t double-post.
The philosophy is deliberate: aggressive about telling you, conservative about touching the platform twice. A duplicate post in front of a client’s audience is worse than a late one — the engine is built around that ranking.
15 seconds → 30 minutes
Temporary problems are tried again after a delay that grows from 15 seconds up to 30 minutes. Every attempt appears in the receipt.
The publish call fires exactly once
Safe checks can run again. The one step that creates the public post is never repeated blindly, so a retry cannot create a duplicate.
Unconfirmed is a state, not a guess
If a platform stops responding at the wrong moment, Publishly tells you the result is unknown and asks you to check before trying again. It never guesses and repeats the post.
A regular recovery check catches missed times
If a recent schedule time is missed during a restart or service problem, Publishly finds it within the hour and queues it again when the account is healthy.
Publishly tries temporary failures again after 15 seconds to 30 minutes, but never repeats the step that could create a duplicate post.
Know a token’s dying before your post does.
Platform connections do not last forever. LinkedIn access tokens, for example, are commonly issued for 60 days, while TikTok access tokens are much shorter and normally renew in the background. Publishly records the expiry the platform reports instead of pretending every network uses the same timer.
The moment a refresh fails, you get an in-app alert & an email — not a red icon you discover next week. The account is flagged & excluded from delivery, so its queue stops cleanly instead of posting into nothing.
One dead account shouldn’t break your whole content calendar.
A dead connection is held back on its own — the other brands, clients, and locations on the calendar keep publishing while you reconnect the one that broke.
When the reported expiry is far enough away, Publishly warns at the 30, 14, 7, 3, and 1-day checkpoints. Shorter connections warn at the checkpoints they actually cross.
A real status page. Real delivery data.
These numbers come from service checks and finished post deliveries. If there is not enough evidence yet, Publishly says that plainly instead of showing a made-up 100%.
Tell you quickly. Retry carefully. Never risk posting the same thing twice just to make a dashboard look green.
Questions operators ask
How do I know when a scheduled post fails?
Publishly alerts you as soon as it knows. The post shows a plain-English reason, whether it will be tried again, and what you need to do. Developers can receive the same details in their own software through a signed failure event.
What happens when a social media API token expires?
Where a platform allows renewal, Publishly refreshes the connection automatically. If that renewal fails, you get an in-app alert and an email, and that account is held back so more posts are not lost while you reconnect it.
Does Publishly retry failed posts automatically?
Temporary problems such as rate limits, platform outages, and network errors are tried again after a safe delay. Problems that need your action or different content are held with an exact reason instead of being repeated blindly. A regular recovery check also catches recently missed schedule times.
Can a retry cause a duplicate post?
No. The publish call itself fires exactly once per delivery; retries only re-run the safe steps around it. If a platform outcome can’t be confirmed, the post is marked outcome_unknown and you’re asked to check the account — it is never silently replayed.
How does Publishly detect a disconnected account?
Scheduled token refreshes and delivery attempts both surface dead connections. A revoked or disconnected account is flagged, excluded from delivery, and raised with a reconnect alert — one dead account never breaks the rest of the calendar.
Stop finding out from your clients.
Connect a channel, schedule a post & read its receipt. Free forever plan — no credit card. 7-day trial on every paid plan.