1 min lesson
Retryable vs non-retryable: stop hammering a 400
Choose two examples from the table in "Retryable vs non-retryable: stop hammering a 400" and explain what each teaches you to do.
Step 1 of 2
Retryable vs non-retryable: stop hammering a 400the classification that saves your error budget
Not every failure deserves a retry. A 500 or a timeout might succeed next time. A 400 or a 401 will fail identically on every attempt, so retrying just burns capacity and delays the moment you notice the real problem.
- Failure
- 5xx server error
- Retry?
- Yes, with backoff
- Reasoning
- Likely transient - overload, deploy, dependency blip
- Failure
- Timeout / connection reset
- Retry?
- Yes, with backoff
- Reasoning
- Network or slowness; the request may simply not have landed
- Failure
- 429 Too Many Requests
- Retry?
- Yes, but honor Retry-After
- Reasoning
- Explicit backpressure; respect the header instead of guessing
- Failure
- 4xx (400, 401, 404, 422)
- Retry?
- No - straight to DLQ
- Reasoning
- Bad request, bad auth or gone; retrying changes nothing
| Failure | Retry? | Reasoning |
|---|---|---|
| 5xx server error | Yes, with backoff | Likely transient - overload, deploy, dependency blip |
| Timeout / connection reset | Yes, with backoff | Network or slowness; the request may simply not have landed |
| 429 Too Many Requests | Yes, but honor Retry-After | Explicit backpressure; respect the header instead of guessing |
| 4xx (400, 401, 404, 422) | No - straight to DLQ | Bad request, bad auth or gone; retrying changes nothing |
Hammering a permanently-broken endpoint wastes your throughput and hides the signal that something needs human attention.