What should happen when a post only half-works?
When a post is sent to several destinations and a destination fails, the honest result is not 'done'. Each destination should report its own status, failures should be visible, and the overall summary should reflect the worst outcome until every failure is resolved.
Why is partial success the normal case rather than the edge case?
When a single request fans out to several destinations, each one is a separate system with its own authentication, rate limits, content rules and availability. The idea that every destination will accept the same payload at the same moment is not a safe assumption. A token can expire, a feed can reject a link preview, a platform can be down for maintenance. Partial success is therefore not a rare bug; it is the expected shape of running a single action across many independent systems.
Treating partial success as normal changes the design. An interface built for the happy path will hide the failed destination behind a green check. An interface built for reality will show each destination as its own row with its own state, because the whole point of multi-posting is reach, and reach is only known per destination.
Why is a single 'Done' over mixed results the most expensive kind of wrong?
A single confirmation collapses several independent outcomes into a single claim. If some destinations accepted the post and another rejected it, the word 'Done' tells the operator that the job is finished. They close the tab, schedule the next task, and only find the gap later, after the moment to correct it has passed. The cost is not just the missing post; it is the work done on a false belief.
The more trust the operator places in the summary, the more expensive the error becomes. A team may plan a launch around a post that never went live on the platform where their audience actually is. The correction is cheaper if the failure is visible in the first summary. Hiding it behind a single status saves a few pixels and spends trust.
What does a per-destination result need to carry to be actionable?
A useful per-destination result is not merely success or failure. It should identify the destination, the state of the attempt, and what the operator can do next. Without the next step, a red mark only adds anxiety. With it, the operator can decide whether to retry, edit, or skip.
| State | What it tells you | Safe next action |
|---|---|---|
| Posted | The destination accepted the content | No action; record the destination for later checks |
| Rejected | The destination refused the content, often with a reason | Read the reason, adjust the content, or skip the destination |
| Rate-limited | The destination asked to slow down | Wait, then retry once the limit clears |
| Timeout | No clear answer arrived before the attempt ended | Retry with a short backoff, then surface as failed if it repeats |
Why should the summary colour follow the worst outcome rather than the best?
A green summary next to a partly red list teaches the reader to ignore the summary. If the headline says 'Done' while a row says 'Failed', the headline and the row contradict each other. The reader has to do the work of reconciling them, which is the opposite of what a summary is for.
A summary that follows the worst outcome, showing amber for partial and red for failed, makes the mixed state visible at a glance. It does not need to be alarming; it needs to be accurate. When every destination has succeeded, green is earned. When any has not, the summary should say so.
- Partial success
- Some destinations accepted the post while others did not
- Per-destination result
- A record of the outcome for a single destination, including any error or next step
- Worst-outcome summary
- A headline status that reflects the least successful destination rather than the most successful
- Actionable retry
- A retry choice that includes what changed or when to try again, not a blind repeat
How should a retry behave when only some destinations failed?
A retry should be scoped, not global. Re-posting to every destination because some failed creates duplicates on the destinations that already succeeded, which is its own form of partial failure. The retry action should target only the failed rows and preserve what was learned from the first attempt.
If the failure reason suggests a content change, the retry should let the operator edit before sending. If it suggests a temporary limit, the retry can wait. Either way, the system should record that a retry happened separately from the original attempt, so the operator can see the full history of what was tried.
Common questions
What counts as partial success in a multi-destination post?
Partial success means the post reached at least some of the intended destinations and failed on others. The failure may be a rejection, a timeout, or a rate limit. The key point is that the outcome is mixed, so a single success or failure label would be misleading. The operator needs a row for each destination to see which ones still need attention.
Should a failed destination block the whole post?
Usually not. If the post already went out elsewhere, blocking the whole action would create duplicates on a retry. A better approach is to keep the successful destinations untouched and treat the failed destination as a separate item. The operator can then decide whether to retry, edit, or skip that destination without disturbing the ones that worked.
How do I decide whether to retry a failed destination?
Look at the reason the destination returned. A temporary limit or timeout may clear on its own, so a scoped retry after a short wait is reasonable. A rejection with a specific content reason usually needs an edit first. If the same destination fails repeatedly, it may be better to skip it and note the gap than to keep retrying blindly.
Why do some tools report success when a destination failed?
Some tools summarise at the level of the overall run. If the run completed without crashing, they call it done, even when individual destinations rejected the post. This is often a design choice to keep the interface simple, but it hides the mixed outcome. A per-destination summary is more honest and makes the next action clear.
If you want an agent that reports per-destination results instead of a vague done, see how GROX handles multi-step work.