How to retry downloads automatically using wget

Transient failures can break an otherwise valid download long before the remote file is actually unavailable. Explicit retry controls let wget ride through short backend problems, temporary network faults, and brief rate limits without requiring a manual restart.

GNU wget already retries a transfer when the connection drops midway through the current invocation. --tries sets the retry budget, --waitretry adds linear backoff between failed retrievals, and --retry-on-http-error or --retry-on-host-error extend what wget treats as transient instead of fatal.

Retries still need boundaries. Permanent errors such as a missing file, bad credentials, or a wrong hostname should fail fast, while --tries=0 should be reserved for jobs that are already supervised by an outer timeout or queue. If an earlier run already left a partial file on disk, use -c for that separate resume case instead of assuming it is required for the current retry cycle.

1. Retry temporary HTTP 503 failures with an explicit attempt budget and retry delay.

   $ wget --tries=3 --waitretry=2 --retry-on-http-error=503 https://downloads.example.net/files/unstable-256k.bin
   --2026-04-22 09:14:22--  https://downloads.example.net/files/unstable-256k.bin
   Resolving downloads.example.net (downloads.example.net)... 203.0.113.50
   Connecting to downloads.example.net (downloads.example.net)|203.0.113.50|:443... connected.
   HTTP request sent, awaiting response... 503 Service Unavailable
   Retrying.
   
   --2026-04-22 09:14:23--  (try: 2)  https://downloads.example.net/files/unstable-256k.bin
   Connecting to downloads.example.net (downloads.example.net)|203.0.113.50|:443... connected.
   HTTP request sent, awaiting response... 503 Service Unavailable
   Retrying.
   
   --2026-04-22 09:14:25--  (try: 3)  https://downloads.example.net/files/unstable-256k.bin
   Connecting to downloads.example.net (downloads.example.net)|203.0.113.50|:443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 262144 (256K) [application/octet-stream]
   Saving to: 'unstable-256k.bin'
   
        0K .......... .......... .......... .......... .......... 19% 48.2M 0s
      250K ......                                                100% 52.1M=0.004s
   
   2026-04-22 09:14:25 (52.1 MB/s) - 'unstable-256k.bin' saved [262144/262144]

   --waitretry=2 lets wget pause between failed attempts instead of hammering the same endpoint immediately.

2. Broaden the retry list only when the upstream uses specific HTTP codes for short-lived overload or gateway failures.

   $ wget --tries=5 --waitretry=10 --retry-on-http-error=429,500,502,503,504 https://downloads.example.net/releases/platform-agent-2026.04.22.tar.xz

   GNU Wget documents --retry-on-http-error as a special-case override. Keep the list narrow so permanent client errors still stop the job quickly.

3. Add host-level retry flags only when DNS or socket failures are expected to clear on their own.

   $ wget --tries=5 --waitretry=5 --retry-on-host-error --retry-connrefused https://downloads.example.net/builds/edge-agent-nightly-2026.04.22.tar.gz

   These flags can hide real naming, routing, or service-state mistakes, so do not use them as a blanket default for every download.

4. Verify that the file recovered successfully before another tool consumes it.

   $ ls -lh unstable-256k.bin
   -rw-r--r-- 1 user user 256K Apr 22 09:14 unstable-256k.bin

   If an older failed run already left a partial file in place, use -c for that separate resume workflow rather than expecting it to change the current retry loop.