Transient outages, upstream faults, and service instability events.
Last reviewed: March 3, 2026|50 mapped errors|Page 3 of 4
Availability errors indicate that service execution failed or upstream dependencies could not complete in time for the current request path.
Provider-specific error pages mapped to this category (50 total). Showing 31-45.
GCP INTERNAL means a Google Cloud service or backend dependency hit an internal invariant, assertion, or unexpected state failure while processing the request.
GCP UNAVAILABLE means the service is currently unavailable or the serving path could not accept the call. It is usually transient, but only explicitly safe calls should be retried with backoff.
GCP UNIMPLEMENTED means the called method, RPC, API surface, or feature is not implemented by the selected Google Cloud endpoint, version, region, emulator, or backend route.
GCP UNKNOWN means the RPC or REST-gRPC translation path returned an unclassified failure because a more specific canonical status was missing, stripped, or could not be mapped.
HTTP 100 Continue is an informational success code indicating that the server has received the request headers and the client is cleared to transmit the request body. It serves as a bandwidth-saving handshake for large-scale data uploads.
HTTP 102 Processing is a deprecated informational status code primarily used in WebDAV environments. It acts as an interim response to tell the client that a long-running request (like COPY or MOVE) is still active, preventing a connection timeout before a final response is sent.
HTTP 202 Accepted is a success status code indicating that a request has been received but processing is not yet complete. It is the gold standard for asynchronous operations, allowing the server to decouple request acknowledgment from task execution.
HTTP 206 Partial Content is a success response indicating that the server is sending only a specific portion of a resource, as requested by the client via a Range header. It is the architectural backbone of video streaming, resumable large-file downloads, and multi-part byte-serving.
HTTP 451 Unavailable For Legal Reasons means access is denied due to legal demands or legal policy constraints.
HTTP 500 Internal Server Error means the application or a dependency hit an unexpected failure path and the server could not return a valid response.
HTTP 501 Not Implemented means the server does not support the functionality required to fulfill this request.
HTTP 502 Bad Gateway means a gateway or proxy received an invalid response from an upstream server.
HTTP 503 Service Unavailable means the server is temporarily unable to handle the request due to overload or maintenance.
HTTP 504 Gateway Timeout means a gateway or proxy did not receive a timely response from an upstream server.
HTTP 505 HTTP Version Not Supported means the server does not support the major HTTP version used in the request.
Compare Guide
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Compare Guide
Fix upstream errors faster: use 502 when a gateway gets an invalid upstream response, and 504 when the upstream service exceeds your timeout budget.
Playbook
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Playbook
Triage 500, gRPC UNKNOWN, and cloud InternalError fast: preserve correlation IDs, separate transient provider faults from app bugs, and apply safe retries.
500 indicates internal server failure, 502 indicates invalid upstream response, 503 indicates temporary unavailability, and 504 indicates upstream timeout.
Retries worsen outages when they are unbounded or synchronized, because they increase load on already degraded dependencies.
Sustained normalization of error rate and tail latency under representative traffic, not only short success bursts.