Answer: Retry only the failed platform jobs. Check Postifys history first, use exponential backoff, and never blind-replay a whole multi-platform fan-out after a partial success.
Why blind retries are dangerous
A fan-out that succeeded on Instagram but failed on YouTube will create a duplicate Instagram post if you replay the entire workflow.
Safe retry checklist
- Read Post History (or your stored job ids) and mark each destination success/fail.
- Branch in n8n: only failed destinations continue.
- Backoff on rate limits and “processing” states.
- Change media/title only when the failure reason requires it (e.g. empty YouTube title).
- Stop after a fixed attempt budget; alert a human.
Deep dive: retries & idempotency · partial multi-platform recovery · idempotency docs
What this means in a real publishing workflow
An n8n retry should begin from a recorded failed Postifys event, not by rerunning the entire original workflow. This preserves successful branches and makes the corrected input or regenerated media explicit.
Recommended implementation
- Read the failure reason and retry stage from Post History.
- Correct the title, credentials, destination, or source media.
- Retry the failed destination only.
- Update the source row with the retry time and resulting state.
How to verify the fix
Do not retry queued or processing events. For expired temporary URLs, generate a fresh media link before requesting another upload.
Operational check: Test with one item, confirm the final destination and Postifys history state, and only then enable the recurring workflow. Keep the returned Postifys ID beside the source row so every result remains traceable.
Related Postifys resources
API documentation · Error reference · n8n automation guide · Safe retry guide · Compatibility matrix