CalcSnippets Search
CLI 2 min read

`curl --retry` and `--retry-all-errors` Are the Flags You Should Use Before Calling a Flaky API Script Broken

A practical guide to curl retry flags so scripts handle transient network and HTTP failures more cleanly instead of failing on the first bad moment.

Why these flags matter: a lot of shell automation is more fragile than the API it talks to because the script gives up on the first transient error.

If you call external APIs, registries, webhooks, or downloads from shell scripts, curl’s retry support is one of the simplest ways to make those scripts less brittle.

The baseline pattern

Start here:

curl --retry 5 --retry-all-errors https://example.com/api

This tells curl not to fail immediately on the first bad moment. That is often exactly what you want in CI, cron jobs, and deployment helpers where short-lived network glitches are normal.

Why this matters in the real world

Transient failures happen constantly:

  1. DNS lookup hiccups
  2. connection resets
  3. temporary TLS issues
  4. slow upstreams
  5. brief 5xx windows

If your script treats every one of those as a final verdict, then the script is often the fragile part of the system.

Pair it with failure handling

A practical pattern is:

curl --fail-with-body \
  --retry 5 \
  --retry-all-errors \
  --retry-delay 2 \
  https://example.com/api

This gives you several useful behaviors:

  1. non-success status can fail the command
  2. response body is still visible
  3. retries happen automatically
  4. the script is less likely to die on one transient failure

That is a much better default for automation than bare curl calls with zero retry logic.

Why --retry-all-errors matters

Older retry behavior often focused on a narrower class of retryable problems. --retry-all-errors is useful when the goal is resilience in automation rather than ultra-conservative behavior.

You still need judgment. Not every request should be retried blindly, especially if the endpoint is not idempotent. But for many GETs, status checks, artifact downloads, and similar calls, it is a very practical improvement.

Final recommendation

If a shell script talks to anything over the network, stop assuming first-failure behavior is good enough. Add curl retry logic intentionally, especially for idempotent calls, and make transient failures less expensive.

Sources

Keep reading

Related guides