HTTP Status Code Checker
Complete HTTP 2xx, 3xx, 4xx and 5xx reference and debugging guide.
200 OK
38 ms
HTTP/2
0
cloudflare
What does this status mean?
HTTP 200 OKWhat it means:
The standard response for successful HTTP requests.
Common causes:
- •Server successfully processed the request and returned the payload
- •Target resource or endpoint is fully operational
- •DNS resolution, TLS handshake, and routing executed nominally
curl -I https://uptara.co“What HTTP response did this URL return?” Inspects RFC response status codes, redirect hop chains, and remediation guides.
“Is this API healthy, how fast is it, and what headers did it return?” Measures multi-region uptime, round-trip latency, and payload bodies.
HTTP Status Code Reference
Explore standard RFC status codes across 2xx Success, 3xx Redirection, 4xx Client Error, and 5xx Server Error categories.
The standard response for successful HTTP requests.
The request succeeded and a new resource was created.
The request has been accepted for processing, but processing is not yet complete.
The server successfully fulfilled the request and there is no additional content to send in the payload.
The server is delivering only part of the resource due to a Range header sent by the client.
The target resource has been permanently assigned a new canonical URI.
The target resource resides temporarily under a different URI.
Resource has not been modified since the version specified by If-Modified-Since or If-None-Match.
Target resource resides temporarily under a different URI; client must not change the HTTP method.
Target resource has been assigned a new permanent URI; client must not change the HTTP method.
The server cannot process the request due to malformed syntax or failed validation.
Authentication is required and has failed or has not yet been provided.
The server understands the request but refuses to authorize it.
The requested resource could not be found on the server.
The request method is understood by the server but not supported by the target resource.
The server timed out waiting for the client to complete sending the request.
The request could not be completed due to a conflict with current server state.
The target resource has been permanently deleted with no forwarding address.
Request syntax is well-formed, but the server cannot process the contained instructions.
The user has sent too many requests in a given amount of time (rate limited).
The server encountered an unexpected condition preventing it from fulfilling the request.
The server does not support the functionality required to fulfill the request.
The proxy/load balancer received an invalid response from the upstream server.
The server is currently unable to handle the request due to temporary overload or maintenance.
The proxy/load balancer did not receive a timely response from the upstream server.
The server does not support the major HTTP protocol version used in the request.
Cloudflare successfully connected to the edge, but the origin web server refused the TCP connection.
The standard response for successful HTTP requests.
Typical Root Cause:
The server successfully processed the request and returned the requested payload.
Remediation & Fix:
No action needed. Nominal healthy state.
Debug with cURL:
curl -I https://api.yourdomain.com/v1/health
Troubleshooting Common HTTP Errors
Detailed step-by-step remediation procedures and root-cause analysis for the 9 most frequent API error codes.
HTTP 502: Bad Gateway
The reverse proxy (Nginx, ALB, Cloudflare) received an invalid or terminated response from the upstream application server.
Common Causes in Production:
- •Upstream application process crashed or failed to start
- •Process killed by Linux kernel Out-Of-Memory (OOM) killer
- •Upstream service listening on a different port or UNIX socket than proxy is configured to forward to
- •TCP connection reset by peer during request processing
Remediation Checklist:
- 1.Check backend process status (systemctl status <service>, docker ps, kubectl get pods)
- 2.Inspect dmesg / kernel logs for OOM killer events (dmesg -T | grep -i oom)
- 3.Verify reverse proxy upstream configuration matches the application listening port
curl -v https://uptara.cocURL Examples for HTTP Inspection
Essential copyable cURL recipes to inspect headers, trace redirect chains, and measure granular network latency.
1. Inspect Status Code & Response Headers
Fetches HTTP response headers and status code without downloading the response payload body.
curl -I https://uptara.co2. Follow and Trace Redirect Chains
Follows 301 and 302 redirect locations, printing headers and status codes for each intermediate hop.
curl -IL https://uptara.co3. Extract Status Code Only (Silent)
Suppresses body output and returns solely the 3-digit numeric status code. Ideal for bash scripts and CI pipelines.
curl -o /dev/null -s -w "%{http_code}\n" https://uptara.co4. Detailed Network Latency Breakdown
Measures granular timing across DNS lookup, TCP handshake, TLS negotiation, and Time to First Byte (TTFB).
curl -o /dev/null -s -w "HTTP: %{http_code}\nDNS: %{time_namelookup}s\nTotal: %{time_total}s\n" https://uptara.coMonitor this API with Uptara
Get alerted when your API returns an unexpected HTTP status code.
30-Second Edge Probes
Probe endpoints every 30 seconds from globally distributed nodes across North America, Europe, and Asia.
Custom Expected Codes
Configure custom expected responses (200, 201, 204, or 401 unauthenticated checks) with instant mismatch alerts.
Instant Escalation
Receive real-time alerts via WhatsApp, Slack, SMS, PagerDuty, and custom webhooks within 2 seconds of failure.
SSL & Latency Tracking
Track round-trip response latency degradation and receive automatic alerts 30 days before TLS certificates expire.
Free tier includes 10 monitors • 3-minute check frequency • No credit card required
Frequently Asked Questions
An HTTP status code is a standardized 3-digit numeric code issued by a server in response to a client's request made to the server. Defined under RFC 9110, HTTP status codes indicate whether an HTTP request has been successfully completed, redirected, or encountered client or server errors.
The Uptara HTTP Status Code Checker issues a live HTTP/HTTPS GET probe from global cloud infrastructure to your target URL. It measures real-time response latency, records the exact RFC status code and status text, detects redirect hops, inspects the negotiated protocol (HTTP/2 or HTTP/1.1), and extracts upstream server headers.
An HTTP 502 Bad Gateway indicates that an edge server or reverse proxy (such as Nginx, Cloudflare, or an AWS Application Load Balancer) received an invalid, terminated, or empty response from the upstream application server hosting the service.
4xx status codes (e.g. 400, 401, 404, 429) indicate client-side errors such as invalid request formatting, missing authentication, or rate limiting. 5xx status codes (e.g. 500, 502, 503, 504) indicate server-side failures such as uncaught exceptions, upstream proxy failures, or backend timeouts.
By default, Uptara expects an HTTP 200 OK response. You can also configure custom expected status codes for specific checks (e.g. expecting 201 for a resource creation endpoint, or 401 for an unauthenticated probe). Any status code differing from your configured expectation triggers immediate alerting.
An HTTP 502 Bad Gateway occurs when a reverse proxy receives an invalid or terminated TCP connection from the upstream app server. An HTTP 504 Gateway Timeout occurs when the reverse proxy waits for a response from upstream longer than its configured timeout window.
API Reliability & Monitoring Ecosystem
Explore connected platform capabilities, in-depth engineering guides, and interactive developer utilities.
Related Capabilities
Recommended Guides
Built for Developers, SREs and DevOps Teams
Free reliability tools for developers and engineering teams detecting downtime, tracking response latency, and calculating real SLAs with Uptara.