Bounded Transient Retry is a single, limited repeat attempt RankGear makes when a request fails for a temporary reason — a network blip, a timeout, a rate limit, or a 5xx server error — rather than a permanent one like bad credentials.
| Term | Bounded Transient Retry |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Transient Retry |
| Where it appears | Bulk Runs |
What it means in RankGear
You meet Bounded Transient Retry in Bulk Runs, where RankGear works through many requests in sequence — pages to fetch, provider calls to make, publishing targets to reach. Any of those can fail for a reason that has nothing to do with your setup: a connection drops, a server returns a temporary error, or an API briefly throttles you. When RankGear classifies a failure as transient, it makes one more attempt before moving on. “Bounded” is the important half of the name: the retry is capped, so a run never falls into an endless loop of repeated calls against a failing endpoint.
How to interpret it
Read the retry alongside the visible status, the run diagnostics, and — where publishing or a provider is involved — a credential test. The point of the mechanism is to separate a transient hiccup, which is worth one more attempt, from a configuration problem, which is not. A timed-out fetch or a rate-limited call is eligible for the bounded retry; an authorization or authentication failure is treated as permanent and stops immediately rather than burning further attempts. If a request keeps failing after its bounded retry, that is a signal to inspect the target or the credentials, not to force more repeats.
| Failure type | Retried? |
|---|---|
| Network drop, timeout, rate limit, 5xx server error | Yes — one bounded attempt |
| Invalid credentials, authorization failure, bad configuration | No — stops immediately |
Example
You launch a Bulk Run over two hundred URLs with remote publishing enabled. One page times out under load; RankGear waits, makes a single bounded retry, and the page comes back on the second attempt. Later in the same run a publishing target rejects the connection because the API token has expired. Because that is an authorization failure, not a transient one, RankGear does not retry it — it stops that item straight away instead of issuing repeated, potentially paid, calls against a target that will keep refusing them.
Important considerations
- The retry is bounded by design: it is one limited attempt, not a loop, which keeps a stalled endpoint from generating repeated or paid calls.
- Only failures classified as transient qualify — credential, authorization, and configuration errors are permanent and are not retried.
- Credentials and remote publishing targets deserve care. Where possible, tests should be read-only, and secrets stay redacted in status and diagnostics.
- A successful retry means the request eventually went through, not that the underlying target is reliable — persistent transient failures still warrant a look at the network path or the provider.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.