wget Exit Codes and HTTP Errors in CI
wget returns a numeric exit status that maps to the failure category, letting a CI step react precisely instead of just retrying blindly.
A failed download is more useful when you read the exit code. wget distinguishes network, auth, and server failures so a pipeline can decide whether to retry or fail.
What it does
wget exits 0 on success and uses distinct non-zero codes for categories of failure: generic errors, network failures, SSL verification failures, authentication failures, protocol errors, and server-issued HTTP errors. The code lets a script tell a transient network blip from a permanent 404.
Common usage
wget -nv https://example.com/app.bin
echo "exit: $?"
# branch on the result
if wget -q https://example.com/app.bin; then
echo "downloaded"
else
echo "wget failed with $?"
fiExit codes
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | Generic error |
| 3 | File I/O error (e.g. cannot write output) |
| 4 | Network failure |
| 5 | SSL verification failure |
| 6 | Username/password authentication failure |
| 8 | Server issued an error response (e.g. 404, 500) |
In CI
Check $? after a download so the job log records why it failed. Retrying helps for code 4 (network) but not for code 8 with a 404, which is a permanent miss. Code 5 means a TLS trust problem to fix with the right CA, not by retrying or disabling checks.
Common errors in CI
Exit 8 with ERROR 404: Not Found means the URL or version is wrong; retries will not help. Exit 8 with ERROR 500: Internal Server Error or 503 is server-side and may be worth a retry. Exit 6 maps to authentication failure, exit 5 to a certificate that is not trusted, and exit 4 to a network failure like Connection timed out.