HTTP 503 (Service Unavailable) is a server response that says the service you asked for can’t handle the request right now — it’s temporarily overloaded or down, not permanently broken.
| Term | HTTP 503 |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | 503 Service Unavailable |
| Where it appears | Provider diagnostics |
What it means in RankGear
When RankGear calls an external provider or a remote publishing target and the other end returns a 503, that outcome shows up in provider diagnostics as a temporary, server-side failure. It is a statement about the provider’s availability at that moment, not about your setup: a 503 does not mean your API key is wrong, your account is out of quota, or a keyword has no data. It means the service simply could not answer the request when RankGear made it.
How to interpret it
Read a 503 as transient. The job is to tell a passing outage apart from a real configuration problem, and RankGear gives you the pieces to do that: the visible status on the row, the diagnostics detail, the retry decision, and a read-only credential test. If credentials still test clean, a 503 is almost always a provider-side hiccup worth a single bounded retry. If authentication fails alongside it, the availability code is a distraction — the fix lives in your configuration, not in waiting for the provider to recover.
| What you see | What it points to |
|---|---|
| 503 and the credential test passes | Transient provider outage — retry once, then move on |
| 503 and authentication also fails | Configuration or credential problem — fix the setup, not the timing |
| Repeated 503s across every request | Provider is broadly unavailable — pause the run rather than burn paid calls |
Example
During a batch pull, a provider’s endpoint returns HTTP 503 for a handful of keywords while it is briefly under load. RankGear flags those rows in provider diagnostics, issues one bounded retry with backoff, and the second attempt succeeds once the provider recovers. Nothing about your credentials changed, and beyond that single retry no extra paid calls are made — the run finishes with the once-failed rows filled in.
Important considerations
- A 503 is temporary by definition. Treat it as a retry candidate, not a permanent failure or a hole in your data.
- Retries are bounded on purpose. RankGear retries once with backoff so a struggling provider is not hammered and paid calls are not multiplied.
- Do not confuse it with authorization errors such as 401 or 403. A 503 means the service is down; those mean your key or permissions are wrong. Run a read-only credential test to tell them apart.
- Credentials and remote publishing targets need care. Diagnostic tests should be read-only where possible, and secrets must stay redacted in diagnostics and logs.
- Provider diagnostics are operational signals about API availability, not Google ranking scores. A 503 says nothing about how a page ranks — only that a request did not complete.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.