Retries hide the bug

A retry is a bet that the same call will behave differently the second time. Sometimes that bet pays. Often it just buries the reason the first call failed.

They turn a failure into a delay

Three attempts with backoff do not remove the error, they move it. What used to be a fast, loud failure becomes a slow one that arrives after the timeout everybody stopped watching.

They make the log lie

If only the final attempt is recorded, the graph shows one failure where there were four. The system looks healthier than it is, right up to the day the retries stop working.

Retry what is actually transient

A dropped connection is transient. A 400 is not. A retry on a request the server already rejected on its merits is a loop with extra steps, and if the call is not idempotent it is a loop that writes twice.

What to do instead

Count every attempt, not just the last. Cap the total time, not just the number of tries. And before adding a retry, read one failure end to end: half the time the fix belongs in the call, not around it.