Design Retry and Backoff Behavior

Feedback & States · errors, offline, undo

Updated 2026-07-28

Retry silently for things the user did not ask for, and ask before retrying things they did. A background poll can recover on its own. A payment cannot.
Space out repeated attempts instead of hammering. Immediate loops make a struggling service worse and drain the battery of the device doing it.
Cap the attempts, then hand control back. An interface that retries forever leaves users unable to tell whether it is working or stuck.
Tell the truth about what is happening between attempts. "Reconnecting" with a next-attempt countdown beats a spinner that has been turning for two minutes.
Only retry what is safe to repeat. Anything that charges, sends, or creates needs a request identifier so a repeat is recognised rather than duplicated.
Distinguish the failures that retrying can fix:

Timeouts and dropped connections, where retrying is reasonable.
Rate limits, where you must wait for the stated window.
Validation and permission errors, where retrying will never work and the user must act.

Give a manual retry that clearly restarts the attempt immediately, and reset the backoff when the user presses it.
Resume rather than restart wherever you can. An upload that fails at 90% and starts from zero is why people give up.

Automatic recovery is only trustworthy when the user can see it happening and can take over at any point.