Scheduled Post Failed? Diagnose and Retry Safely in 2026

When a scheduled post fails, inspect the result for each destination before retrying. A failed response can mean the platform rejected the content, but a lost response can also leave the outcome unknown. Uplonic records that distinction on the publishing task and requires explicit confirmation before retrying a task marked with an unknown outcome.

A request can succeed on one network and fail on another. If you distribute the same source widely, the one-video crossposting workflow explains why each destination still needs its own settings. Recreating the entire request can unnecessarily repeat the successful destinations.

Before you start: find the exact failed attempt

This guide uses the API. You need the workspace's API base URL, a key with write access, the publishing request ID and the task IDs you intend to inspect. Send the key in the x-api-key header. Work in the workspace that owns the request.

Request GET /uploads/requests/REQUEST_ID. Inspect the task's status, platform, lastErrorClass, lastErrorMessage, unknownOutcome and any platformUrl. Also inspect the parent request's status. Do not use the parent status alone to decide what to resend.

Separate an unknown outcome from a known failure

If unknownOutcome is true, open the destination account and look for the intended post. Check the account identity, source content and approximate attempt time. If you find the post, stop: retrying can create a duplicate. If you cannot determine the result, preserve the error details and resolve the uncertainty before confirming.

This is the same underlying concern discussed in HTTP Semantics, section 9.2.2, checked 2026-10-17: retrying an operation whose effect is uncertain needs care. HTTP status alone does not establish whether a non-idempotent publishing operation took effect.

If the outcome is known, address the recorded cause. An inactive connection needs reconnection to the intended account. A rejected video needs a corrected file or settings. A task whose media has been removed cannot be repaired just by pressing retry.

Request a retry without confirming unknown outcomes

Send POST /uploads/requests/REQUEST_ID/retry with the chosen failed task ID. The JSON below uses placeholders for your identifiers and deliberately leaves unknown-outcome confirmation false.

{
  "taskIds": ["TASK_ID"],
  "confirmUnknownOutcome": false
}

Read both retried and skipped in the response. A successful HTTP response can still report that nothing was retried. In the dev check dated 2026-10-17, the unknown-outcome fixture returned retried: 0 with needsConfirmation: true on the skipped task. That is a deliberate refusal to make the publishing decision for you.

If the response includes a skip reason that does not need confirmation, fix that condition first. The test also checked refusal for an inactive destination and for a video marked as removed from storage. Confirmation does not override those conditions.

Confirm only after checking the platform

Once you have checked the destination and chosen to retry, send the same selected task with confirmUnknownOutcome set to true. This is a publishing decision, not a repair for an expired connection or a missing file.

{
  "taskIds": ["TASK_ID"],
  "confirmUnknownOutcome": true
}

In our 2026-10-17 synthetic test, the confirmed task returned to queued, its attempt counter reset and its manual-retry count increased. The parent request reopened, while the sibling task that was already completed stayed completed. Those observations verify retry selection and persistence; they do not guarantee a successful provider response on the next attempt.

Check the result and resolve common blockers

Fetch the request detail again. A queued or processing task still needs an outcome. Check its final status and returned destination URL, then confirm the post on the correct account. Avoid submitting another fresh publish request while the retry is still pending.

Use the video specification checker for media-format diagnostics. If a repeating rule keeps creating attempts, review and pause its future selections using the recurring schedule setup guide while you investigate. Pausing that rule and resolving an already-created request are separate actions.