Publishing status and reliability

Each platform's state comes from the final outcome of the posts Ampost published to it, for all customers together. Only aggregates appear here: no accounts, posts or counts. A post counts once, when it was published or when it failed for good after its retries.

Failures caused by the post or the account are not counted, because the platform works: invalid or oversized media, text over the limit, a login that expired, a missing permission. The rest (the platform refusing or not answering, a rate limit that outlasted the retries, an Ampost error) count against the platform.

Operational means at least 95% of those publishes succeeded (a single failure never lowers it), degraded at least 80%, disrupted less. Ampost's own alarm checks the last 3 hours every 15 minutes and alerts the team when a platform drops or a new error starts to repeat.

When a publish fails for a reason that passes (the platform's rate limit, a timeout, a network error, a 5xx), Ampost publishes again by itself, up to 5 attempts in all, waiting longer each time (up to 1, 2, 4 and 8 minutes) with random jitter, so many failed posts do not all retry at once. The wait is never shorter than the platform asks for in its Retry-After or rate-limit reset.

Meanwhile the account stays pending with attempts and nextAttemptAt, and no webhook fires. Only the final outcome fires post.published, post.partial or post.failed. A failure that will not pass by itself (an expired login, invalid media) fails at once with a clear error code.

Every platform caps how much one account, and one app, may post: Instagram and Threads per day, X per 15 minutes and per day, LinkedIn and TikTok per day. Ampost keeps each account a little under those limits and queues the rest. A burst of posts due together publishes in turn instead of failing, and waiting in the queue never uses up a retry. When a platform does answer "rate limited", the other posts of that account wait for the reset instead of failing too.

A timeout can come after the platform already created the post. Before such a retry, Ampost looks for the post on the account (Instagram, Facebook feed, Threads, Bluesky, YouTube, Pinterest) and publishes again only if it is not there. Where a platform offers no way to check, the account fails with PUBLISH_OUTCOME_UNKNOWN instead of risking a second copy.

Your own retries are safe too. Calls that create or publish accept an Idempotency-Key header (or idempotencyKey in MCP): the same key within 24 hours returns the first result instead of posting again.

Ampost renews Instagram and Threads logins 30 days before they expire, even for an account that has not posted in weeks, and renews TikTok, X, LinkedIn, Bluesky, YouTube and Pinterest logins when they are used. When a login is about to run out for good and only you can reconnect it, Ampost says so a week ahead: the account's health shows the issue, the account.needs_reconnect webhook fires and the owner gets an email. Reconnecting keeps the account, its posts and its settings.

You can, and then retries, backoff, per-platform quotas, duplicate checks and token renewal are yours to build and run, nine times over. Ampost does them once behind one API and one MCP server. See the API docs, the platform guides or start free.