A rate limit is a provider-imposed cap on how many requests you can send in a given window; cross it and the provider temporarily rejects otherwise-valid calls, most often with an HTTP 429 response.
| Term | Rate Limit |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | HTTP 429, Too Many Requests |
| Where it appears | Provider errors and retry decisions |
What it means in RankGear
RankGear calls external providers on your behalf — search-data APIs, AI models, and publishing endpoints — and each of those providers enforces its own ceiling on request frequency and volume. When RankGear pushes past that ceiling, the provider answers with a rate-limit error instead of the data you asked for. This surfaces in the provider-error and retry area: a run that was moving normally pauses or flags a request as throttled, which is distinct from a request that failed because a key or scope was wrong.
How to interpret it
A rate-limit error is a signal about pacing and timing, not about whether your configuration is valid. Read it alongside the visible status, the diagnostics, the retry decision RankGear made, and a credential test. A 429 that clears on a slower retry means you were simply sending too fast; the same request failing with an authorization error means the credential or scope is at fault and no amount of retrying will fix it. In practice: back off and space requests out for a rate limit, but stop and re-check setup for an authorization failure.
| Provider response | What it tells you |
|---|---|
| HTTP 429 (rate limit) | Too many requests too fast — back off and retry with spacing. |
| Timeout | The provider was slow or unreachable — one bounded, longer retry is reasonable. |
| HTTP 401 / 403 (auth) | Credential or scope is wrong — stop; retrying only wastes paid calls. |
Example
During a large batch, RankGear fires dozens of provider calls in quick succession and the provider returns HTTP 429 on several of them. RankGear waits, then issues one bounded, slightly longer retry for the throttled calls, and they succeed the second time. A separate request in the same run that comes back with a 401 authorization error is not retried — repeating it would only burn paid calls against a credential the provider has already rejected.
Important considerations
- A rate limit is temporary and comparative to the provider’s plan. It reflects the provider’s ceiling and your request pace — it says nothing about page quality or ranking, and it is not a verdict on your work.
- Different providers set different windows and thresholds, and a higher-tier plan usually raises them. Two providers throttling at different points is expected behavior, not a defect.
- Bounded retries help with throttling and timeouts, but retrying an authorization or configuration failure does not — RankGear stops those to avoid wasting paid calls.
- Credentials and remote-publishing targets deserve care: tests should stay read-only where possible, and secrets must remain redacted in logs and diagnostics.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.