Timeouts and a Retry Policy — The Failure Decisions Product Managers Own

The Network Will Fail Eventually

Everyone has watched a screen hang after tapping a button. The server is slow, the connection drops for a moment, a response starts and never finishes — this is not an exception but something that happens all the time, normally. Every request that crosses the internet will fail eventually. The question isn't "will it fail" but "what do we do when it does" — and a retry policy is what settles that answer in advance.

Its two axes are timeouts (how long to wait) and retries (how many times to try again). And a retry policy is not just an engineer's technical choice. Because it decides "how long we make the user wait" and "what we show when it fails," it is, at its core, a planning decision. This post lays out the judgment behind it, at a level that needs no code.

Timeout — How Long Will You Wait?

A timeout is the limit that says "if there's no response after this long, treat it as a failure." Why is it needed? If you wait forever, the user stares at a frozen screen indefinitely, and the server holds an unfinished request until it runs out of resources. One request that never ends blocks the ones lined up behind it.

So you have to draw a line: "wait only this many seconds." Draw it too short and healthy requests get failed; too long and the user gives up. The right timeout is a question of user experience, not technology — "on this screen, how many seconds will a user wait?"

Retry — Again on Failure, but Carefully

Once a timeout detects failure, the next choice is a retry. Transient problems (a brief network blip) usually succeed on a second attempt, which makes retries a powerful tool. But retrying blindly is dangerous. If retries pile onto a struggling server, they can topple it completely.

What a Retry Policy Should Decide

A good retry policy settles three things up front.

How Many Times to Try Again

Infinite retries are forbidden. Usually you stop at two or three, and if it still fails, you accept the failure and tell the user. "Until it works" is not a policy — it's an incident.

At What Interval to Retry

Retrying immediately, several times in a burst, only stacks load on the server. So you widen the gap between attempts — one second later, then two, then four. Spacing them out gives a struggling server room to breathe and time to recover. (This is called "exponential backoff," but a product manager only needs "widen the interval.")

What Must Not Be Retried

The most important item. A read is safe to repeat any number of times, but an action like a payment or an order turns a retry into a duplication risk. If "the payment succeeded but the response got lost," retrying can charge the same payment twice. So these actions must be designed together with a safeguard called idempotency — so that even if the same request arrives many times, the result applies only once.

When Retries Turn Dangerous — the Retry Storm

The classic retry failure is a "retry storm." A server slows down for a moment, and countless clients all at once go "failed, try again!" and hammer it with retries. A server that would have recovered with a brief rest collapses entirely under the flood. The retries meant to recover from failure end up amplifying the outage.

That's why restraint is the heart of retrying: widen the interval, cap the count, and give up cleanly when it won't work. When retries are exhausted and it still fails, you move to a fallback — showing stale cached data, or a "please try again shortly" message.

What a Product Manager Should Decide

The technical implementation of a retry policy belongs to developers, but the standards are set by planning.

• How long to make them wait: how many seconds will a user tolerate on this screen — and how you show a loading state within that window.
• What to show on failure: the copy when all retries fail. "A network issue occurred, please try again" beats a bare "an error occurred."
• What must not be retried: list the actions that must never duplicate — payment, order, submission — and share it with the engineering team.

Failure Is the Default, Not the Exception

The essence of a retry policy, in one line: failure is not an occasional exception but a constant default. So what separates a polished service is deciding "what happens when it doesn't work," not just "what happens when it does."

And half of that deciding belongs to planning — how long to wait, how many times to try, what must never be retried, and what to show when it finally fails. Like caching or a fallback, it's an invisible decision that makes users trust the service. Next time you ask for "please build this feature," add one sentence: "and what happens when it fails?"