Separate an HTTP response from a request failure
A check with HTTP 503 reached an HTTP endpoint and received a response. A TLS validation error or DNS error can occur before any HTTP status exists. Start with that distinction; otherwise you can spend time searching application logs for a request that never reached the application.
Open the monitor and note the exact URL, result time and reason. UpBastion treats final HTTP 2xx statuses as successful. All other final statuses, rejected redirect targets and connection errors fail the check. Two consecutive failures are needed to open an incident. See how checks work for the request and confirmation rules.
HTTP codes classify the response, but do not identify the exact system that generated it. A proxy, CDN or application can produce an error. Compare response headers and logs with your architecture before naming a cause.
Reproduce the request with the same method
Use GET when checking a result from UpBastion. curl -I uses HEAD, which an application can handle differently. The following command makes a GET, follows up to five redirects, discards the body and prints the final status and total duration. Replace the example address with your URL.
curl --location --max-redirs 5 --max-time 15 \
--user-agent 'upbastion-monitor/1.0' \
--output /dev/null --silent --show-error \
--write-out 'status=%{http_code} total=%{time_total}s final=%{url_effective}\n' \
'https://example.com/'The curl manual documents these options. This is a diagnostic approximation from your own network, not an exact copy of the worker. DNS, routing, source address, TLS library and connection behavior can differ. A successful local command does not invalidate a failure observed by another server.
To inspect the redirect chain, use --dump-header - as well. Review the output before sharing it: headers can contain cookies or other sensitive information. Keep certificate verification enabled; --insecure removes a condition the UpBastion HTTPS check actually enforces.
A successful code can still describe a broken page
HTTP 200 indicates success at the HTTP level; 204 is also in the accepted 2xx range. UpBastion does not inspect the body or execute the returned page. An error template, empty result or client-side failure served with 200 can remain green.
For a health endpoint, make the response status represent the condition you want to measure. For a full user journey, use a separate test that performs and verifies that journey. Choosing monitor URLs explains how to avoid treating a homepage response as evidence that every function works.
Redirects need a destination and a bounded chain
The worker follows 300–399 responses when a Location header is present, up to five redirects. A chain ending in a successful status is successful. A loop, a sixth redirect, an unsupported destination or a final non-2xx response fails.
Inspect whether the requested hostname is redirecting to the intended address. A redirect to a login screen can hide the fact that the worker never accessed your application's protected area. A redirect to a private network is rejected even when your own browser can reach that network.
The HTTP specification's redirection section explains the standard status family. UpBastion's exact accepted behavior is documented in redirect handling.
Authentication, access rules and missing resources
For a 401, inspect whether the endpoint requires authentication. A 403 indicates that the server refused the request; possible causes include an access rule or application authorization. Neither status is accepted as up. See MDN's 403 reference for the distinction.
A 404 can mean the monitored path no longer exists or that routing reaches the wrong deployment. Test the precise path and hostname, then compare your proxy route and application route. Do not assume a homepage check covers an API path that was removed.
A 429 is a rate-limit response. Inspect the rate-limiting component and its logs; the 429 specification defines the code. A monitor can share a source network with other requests, so your own limit settings and logs matter more than guessing from a single code.
Server and upstream errors
A 500 describes a server-side failure but does not reveal the failing line of code. Match the observation time to application errors and recent deployments. A 502 or 504 commonly directs the investigation toward a gateway and its upstream connection; confirm the relationship in proxy and upstream logs.
A 503 indicates that the responder is unable to handle the request. It can be intentional during maintenance or generated by a failed readiness check. Check the 503 reference and the code that actually generated your response.
When no status was returned, investigate DNS resolution, the public address, network access, certificate validation and deadlines. Keep the observed error separate from your diagnosis. The downtime investigation guide follows those layers in order.
Confirm the fix with a new observation
After making a change, test the same public address without a login session or a certificate bypass. Wait for a new worker result. A single successful check closes an open incident and queues a recovery message, but one observation does not prove every visitor's network path works.
If the same status keeps returning, contact support with the result time, URL, code and a sanitized log excerpt. Describe what you changed and what a successful response is meant to represent.