HTTP 400 means the server, CDN, gateway, or application received the request but considered it invalid. This is different from a DNS, connection, or TLS failure because an HTTP service responded.
Uptime Basics treats HTTP 400 as a failed availability check unless you explicitly add 400 to the monitor's Accepted HTTP status codes.
Check the exact response
- Open the monitor and review Failure Diagnosis.
- Open Detailed Logs and confirm that the HTTP column shows 400.
- Compare nearby checks to determine whether the response is continuous or intermittent.
- Review the exact URL, request method, redirects, custom headers, and authentication settings.
- Check the application, CDN, gateway, or WAF logs at the same timestamp.
One 400 row does not automatically create an incident. The monitor becomes Down only after the normal regional and consecutive-failure confirmation requirements are met.
Common causes
Incorrect URL or query string
Check the protocol, hostname, path, query parameter names, encoding, and required values. Uptime Basics requests the exact path and query string saved in the monitor.
Avoid putting passwords, API keys, session tokens, or personal information in the URL. URLs can appear in dashboards, logs, exports, and support information.
Endpoint expects a request body
Availability monitors support GET and HEAD requests without a custom request body. An endpoint that requires POST, JSON, form data, or GraphQL content can return 400.
Create a safe GET health endpoint instead of trying to reproduce a transactional API request. The health endpoint should return a lightweight response that represents the dependencies needed to serve users.
Missing required header
Some staging, API, or allowlisted endpoints expect a custom header. Add the required non-blocked header under Advanced Request Options. You can save up to 10 custom headers.
Authorization, Cookie, Host, Content-Length, and other connection-sensitive headers cannot be entered as custom headers. Use the Basic Authentication setting for HTTP Basic credentials.
Host, CDN, proxy, or firewall rule
A reverse proxy can return 400 for an unrecognized hostname, malformed forwarded request, strict protocol rule, or bot-management decision. Confirm the hostname is attached to the correct virtual host, CDN distribution, certificate, and origin.
HEAD is handled incorrectly
GET is the default and most compatible option. For a paid monitor configured to use HEAD, Uptime Basics can retry with GET after several method-related HTTP failures, including 400, when enough timeout remains. If GET consistently works, save GET as the monitor method.
Should you accept HTTP 400?
Only accept 400 when that exact response intentionally proves the monitored service is available. For example, a specialized API root might deliberately return 400 for an empty request while still demonstrating that its gateway is reachable.
Before accepting it, answer these questions:
- Is 400 documented as the expected healthy response for this exact endpoint?
- Would the endpoint return the same 400 if an important downstream service failed?
- Is there a better health endpoint that can return a normal success code?
- Are you accepting the code to represent health, or only to hide a persistent error?
If 400 is accepted, future 400 responses count as Up and do not create an HTTP failure diagnosis. That makes the decision important.
Add or remove an accepted code
- Open Monitor Details.
- Open Monitor Tools and Advanced Request Options.
- Enter
400and press Enter to add it. - Save the setting.
Remove the code with its x control when it should no longer represent health. The change affects future checks and does not rewrite earlier history.
When to contact Support
Contact Support if the same URL and allowed request settings return a healthy response externally but Uptime Basics continues to receive HTTP 400.
Include the monitor name, URL, timestamps, request method, redirect setting, and names of relevant custom headers. Do not include header values, passwords, API keys, cookies, or verification codes.