How can I display a retry action without retrying automatically forever?
Quick answer
Set a clear limit for automatic retries, then stop and show a Retry button if the operation still fails. Start another attempt only when the user activates that button. While it runs, show a loading state; on success, show the result, and on failure, return to the error state with the action available again. Make the retry limit and status clear.
The question, the details, the next step.
How can I display a retry action without retrying automatically forever? I want the screen to recover from a temporary failure, but not get stuck in a loop.
Treat automatic retries and a person choosing Retry as separate events. Decide on a maximum number of automatic attempts for one user-initiated operation—for example, two retries after the first attempt. When that limit is reached, stop automatically and display an error with a Retry button. Activating the button starts a new operation; it should not quietly restart an unbounded retry loop.
A useful set of interface states is loading, success, and error. In the error state, explain what failed in plain language and offer Retry if another attempt is possible. If a retry is activated, return to loading and disable the button while the attempt is in progress, so one click does not accidentally launch several requests.
What should count as an attempt, and what should happen after the limit?
For a simple design, count the first attempt as attempt 1 and each automatic retry as another attempt. With a hypothetical limit of three total attempts, the operation runs once, retries automatically at most twice, and then stops. Make the limit a deliberate setting in your application rather than letting a failure handler call itself without a bound.
After the last failed attempt, show the error state, not a spinner. For example: “Couldn’t load the report after three attempts. Try again.” The number and wording are illustrative; choose language that matches your operation. Keep the failure visible until the user retries, leaves the screen, or another relevant action changes the state. Don’t label a failed operation as successful just because the retry limit was reached.
Can you show the flow for a manual retry, including what happens when that attempt fails too?
Assume a page loads a report and allows at most two automatic retries per load. A possible flow is:
- The person selects Load report; show “Loading…” and begin attempt 1.
- If it fails, make up to two automatic retries. If one succeeds, show the report.
- If all three attempts fail, stop and show “Couldn’t load the report” with a Retry button.
- When the person selects Retry, show “Trying again…” and begin one new operation. If it succeeds, show the report. If it fails, return to the error message and offer Retry again; do not start another automatic loop.
Each automatic retry is permitted only while the current operation is below its limit. A button click is a fresh user action, not permission to retry that operation indefinitely. If you also want to limit repeated manual clicks, define and communicate that separate rule.
What details should I check so the button and status don’t contradict each other?
Use one source of truth for the current operation state and attempt count. On a new operation, reset the count; while it is running, show loading and prevent duplicate starts. On success, show the result and remove the retry action. On final failure, stop the automatic logic, show an error, and offer a clearly labeled button such as “Try again.” When that button is selected, begin a new operation and show loading immediately.
For example, if a report fails on all three allowed automatic attempts, the screen should not keep announcing “Retrying…” or leave a permanent spinner. It should say loading failed and let the person decide whether to try again. Check both paths: a retry that succeeds and one that fails. In the second path, confirm that the interface returns to the visible error state instead of restarting itself.
A practical checklist
Choose a maximum number of automatic attempts for each operation.
Count the initial attempt consistently and stop automatic retries at the stated limit.
Show loading only while an attempt is running; prevent duplicate starts.
After the limit, show a clear failure message and a user-triggered Retry action.
On manual retry, start a new operation and return to the error state if it fails.
Check success and repeated-failure paths to confirm no automatic loop remains.
A few more useful answers
Should the Retry button stay visible while an attempt is running?
Usually disable it or replace it with a loading status while the attempt is in progress. Make it available again if that attempt fails and another user-triggered try is allowed.
Should clicking Retry reset the automatic attempt count?
Treat the click as a new operation and apply your defined automatic-retry limit to that operation. Keep any separate limit on repeated manual retries explicit rather than silently reusing or resetting counts.
What should the interface say when the automatic retry limit is reached?
Say that the operation failed and offer a clear next action, such as “Couldn’t load the report. Try again.” Avoid a spinner or wording that suggests automatic retries are still happening.