Scheduled post failed? How to check and recover
Start with the destination result. A rejected caption, expired connection, rate limit, and missing response need different actions. This guide helps you choose the next step.
Check the result for each destination and whether the post already exists on the platform. Then address the recorded cause: reconnect an expired account, correct rejected content, wait for a rate limit, or investigate an uncertain response. Retry only the affected destination when the product says it is safe. A timeout does not prove that nothing published.
First, check whether the post is already public.
Open the campaign or post detail and look at each destination. If a published URL or provider receipt exists, inspect it. If the tool lost the response, check the native account around the attempted publishing time before creating another post.
There are three useful distinctions: confirmed success, confirmed rejection, and unknown outcome. An unknown outcome happens when a platform may have accepted a write but the publishing tool did not receive a conclusive response. Repeating that write can create a duplicate.
If some destinations succeeded, preserve those results. “Partially published” means you need to resolve specific destinations, not start the whole campaign again.
Match the error to the next action.
| What you see | What to check | Next action |
|---|---|---|
| Disconnected or authorization expired | Correct account, token validity, and publishing permission | Reconnect the same intended account, then review the failed destination before retrying. |
| Content or media rejected | Caption, required fields, file format, size, and upload readiness | For a failed delivery, use Reuse as new draft, keep only the failed destinations, correct the copy or media, and schedule the new draft. |
| Rate limited / 429 | Recorded retry time and the provider’s response | Let a scheduled safe retry run. Avoid creating new copies to bypass the wait. |
| Needs review / uncertain result | Native account, attempted time, and any existing receipt | Confirm whether the post exists before deciding whether another delivery is needed. |
| Plan limit reached | Delivery allowance and connected-channel limits | Wait for the allowance to reset or choose sufficient capacity. Check the current plan limits. |
| Still queued after the requested time | Timezone, active queue state, and any platform processing message | Check current status before resubmitting. Contact support if the queue makes no progress. |
These are diagnostic categories, not proof of the cause. An error code without its message and delivery state can be misleading. For example, a server error returned before a write and a dropped connection after a write have different duplicate-post risks.
Recover a failed destination in PostOnce.
- Open Content and select the campaign. Inspect its destination results, attempt history, and available actions.
- Read the destination-specific message. Check whether PostOnce has already scheduled an automatic retry or needs your decision.
- Resolve a known blocker. Reconnect credentials if access expired. If rejected content needs editing after delivery began, use Reuse as new draft, remove already successful destinations, correct the content, and schedule the new draft. Verify the account identity after reconnecting.
- Use manual reconciliation for uncertain outcomes. Compare the destination account with the attempt. Record the confirmed result through the available review flow rather than treating uncertainty as failure.
- Retry only when safe and available. Use the affected destination’s recovery control. If the product does not offer a safe action, contact support with the campaign and error details.
- Confirm the final result. Read the new receipt or status; clicking retry is not proof of publication.
PostOnce keeps destination outcomes independent. It uses bounded automatic retries for eligible failures and holds ambiguous non-idempotent writes for review. The publishing feature overview explains this behavior; the API evaluation guide explains the underlying design.
Did the post fail, or is the schedule different?
Compare the intended local date and time with the timezone shown in the campaign. A local time such as “9:00” is incomplete without a date and timezone. Daylight-saving transitions can also create missing or repeated local times.
Use a named timezone, review the displayed schedule before confirming, and check the actual delivery timestamp afterward. In PostOnce, a campaign shares one schedule across its targets. If your audiences need different local publishing times, create separate campaigns.
A scheduled time is a request to begin delivery. Media processing, queue work, and destination rate limits can delay confirmation. Avoid repeated clicks while a delivery is still queued or processing; first refresh the recorded status.
A short checklist before the next campaign
- Confirm each account is connected and the connector is currently available.
- Check the exact destination caption, required fields, links, and media.
- Wait until uploaded media is ready; use supported file types and sizes.
- Review the date, timezone, and remaining allowance.
- Keep a way to inspect results after scheduling. Delivery status and engagement performance answer different questions.
When contacting support, include the campaign identifier, destination, approximate attempt time and timezone, error message, and whether a native post exists. Never send app passwords, access tokens, or webhook secrets.
Common recovery questions
Will retrying charge me for another post?
PostOnce counts successful destination deliveries. Automatic retries, drafts, and validation failures do not add billed publishes. Creating a separate campaign that successfully posts again is a new delivery, which is another reason to inspect the existing result first.
Does reconnecting fix the failed post automatically?
Reconnecting repairs access when authorization was the problem. It does not prove the old post was delivered. Return to the campaign, review the latest state, and use the action offered for that destination.
Why not retry every timeout?
Some providers support an idempotency key: replaying the same recognized request can avoid another post. Other operations do not provide that guarantee. PostOnce distinguishes these cases instead of assuming every timed-out write is safe to repeat.
Sources
- Mastodon statuses API — an example of provider-defined idempotency and scheduling behavior.
- Mastodon rate limits — an example of rate-limit responses and retry information.
- PostOnce delivery behavior — product-specific queue, retry, and receipt contracts.