Monitors & detections
HTTP monitoring errors: find the next useful clue
Understand 502, 503, 504 and other failed checks, distinguish response errors from connection failures, and investigate without hiding the signal.
Reviewed
Start with the observation
A red result tells you that one request did not meet your monitor’s rules. It does not, by itself, identify a root cause or prove that every customer is affected. Note the time, endpoint, request method and result before changing anything. A useful first question is: what could a customer not do at that moment?
Separate an individual failed check from confirmed downtime. UptimeOwl retains check results, while your consecutive-failure setting determines when the monitor changes state. Read both the recent checks and the detection history so you do not mistake a short fluctuation for a sustained outage.
Read the status code as a clue
502 means a gateway or proxy received an invalid upstream response. 503 means the server is temporarily unable to handle the request. 504 means a gateway did not receive an upstream response in time. These describe where the request failed; they do not tell you which deployment, dependency or capacity issue caused it.
401 points toward authentication, 403 toward refusal of access, and 404 toward an unavailable target resource. A 429 response signals rate limiting. Check credentials, routing and request volume before deciding that the application itself is down.
A DNS error, TLS failure or client-side timeout may happen before an HTTP response arrives. Do not label these as HTTP 504 unless that status was actually returned.
Follow one request through your service
Compare the failed request with an application or proxy log entry from the same time. Use a safe request identifier if one exists. A successful check from your laptop is useful evidence, but it may use another network, cached session or redirect path. It does not invalidate the original result.
- Confirm the exact URL, method, expected codes and redirect setting in the monitor.
- Check recent deployments, certificate or DNS changes, and access-policy changes around the failure time.
- For a gateway error, inspect the upstream it contacted; for authentication errors, review the monitor’s configured credentials without sharing them.
- Repeat a safe read-only request and compare subsequent results. Avoid repeatedly executing endpoints that create orders, send messages or change data.
Do not paint over a red signal
For an endpoint that should return 200, the sample 503 below should remain a failed check. Adding 503 to the accepted codes would hide this symptom; it would not restore service. Accept unusual codes only when they are part of the endpoint’s intended contract.
A Retry-After header can explain the server’s requested delay. It is not a promise of recovery, and UptimeOwl does not use it to reschedule the monitor automatically. Your saved check interval still applies.
HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 120
{"ready":false}Close with evidence
After a fix, look for a steady sequence of expected responses and verify the affected customer action. Keep a short note of what failed, what changed and what you will monitor next. If the problem repeats, use those observations to refine the endpoint or threshold rather than simply making the timeout longer.
UptimeOwl’s monitor editor controls the request and its success rules. Your application and infrastructure logs supply the deeper diagnosis. Keep private response details out of public incident updates.