Retry Logic and Error Handling

The job has been retrying since Friday, the queue holds a file from Wednesday, and the log says "error". Every transfer job fails eventually: the network blips, the partner's server reboots, the disk fills. What separates robust automation from fragile automation is not avoiding failure but responding to it on purpose. That means retrying the failures that deserve retries and quarantining the ones that do not. It means accounting honestly for the job that half-worked, and recovering cleanly instead of demanding a human at dawn.

This series is the failure playbook. It covers telling transient from permanent errors, retry timing and backoff without the folklore, and poison files and the dead-letter pattern. It covers partial failures in multi-file jobs, error messages worth logging, and designing jobs that recover themselves after a crash. None of it prevents the failure at two in the morning. All of it decides whether anyone has to be awake for it.

Articles in This Series

• Transient vs Permanent Failures in File Transfers
  This is the taxonomy that drives everything: network blips versus wrong passwords versus full disks. It covers classifying real error messages, and why retrying a permanent failure makes things worse.
• Retry Strategies: Timing, Backoff, and Giving Up
  This article covers immediate, fixed, and exponential backoff with jitter - in plain words with worked timings. It covers retry budgets, retrying the step versus the whole job, and the retry-forever trap.
• Poison Files and the Dead-Letter Folder
  This article covers the file that fails every single time. It covers detecting it before it clogs the pipeline, the quarantine move, and alerting. It covers reprocessing after the fix, and the postmortem that prevents its siblings.
• Partial Failures in Multi-File Jobs
  Ninety-nine of a hundred files made it. This article covers all-or-nothing versus per-file accounting, manifests as the truth, resume versus restart decisions, and reporting that tells the real story.
• Error Messages Worth Logging (and Acting On)
  This article covers capturing client output and exit codes, and enriching errors with job, file, and host context. It covers deduplicating repeat alerts, and writing messages your future self can act on at a glance.
• Designing Transfer Jobs That Recover Themselves
  This article covers checkpointing progress, safe re-runs, crash-consistent state, and the recover-on-start pattern. It gives a worked example of a job that picks itself up after being killed mid-transfer.

Explore More Topics

This series is part of the Sysax file transfer topic library. The library covers the protocols, security practices, automation techniques, and operational skills behind reliable file transfer. The library pairs well with the practical tools we build. Sysax Multi Server is a secure FTP, FTPS, SFTP, and HTTPS server for Windows. Sysax FTP Automation schedules and scripts secure transfers so the routine ones run themselves.