Free tools

HTTP 400 Bad Request

The server could not understand the request. Free reference, no signup.

400 Bad Request

MeaningThe server could not understand the request.
WhenJSON is invalid, a required field is missing, or a query value is the wrong type.
CausesA malformed body, a bad parameter, or a client bug.
FixRead the error body and fix the request. Retrying the same payload will fail again.
RetryDo not retry until the request changes.
Alert?Usually no. One bad client is noise. Alert if your own service starts sending 400s.

Runs in your browser. Nothing you enter is stored.

Most 400s are not an incident

One bad client is noise. Alert if your own service starts sending 400s.

curl -sS -X POST https://api.trigv.com/v1/events \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer $TRIGV_API_KEY" \
  -d '{"channel":"ops","title":"HTTP 400","level":"warning"}'

How to use it

  1. Read what 400 means before changing a retry loop.
  2. Check the common causes against the response body and the server log.
  3. Follow the retry note. Retrying a 400 with the same body will fail again.
  4. Alert only in the cases the verdict describes.

About this tool

HTTP 400 Bad Request means The server could not understand the request. Servers send it when JSON is invalid, a required field is missing, or a query value is the wrong type.

Common causes: A malformed body, a bad parameter, or a client bug. The practical fix is: Read the error body and fix the request. Retrying the same payload will fail again.

Retry: Do not retry until the request changes.

Alert on it? Usually no. One bad client is noise. Alert if your own service starts sending 400s.

Trigv is a push for the moment a status starts mattering, not a log of every response. If the code is one you should hear about, the snippet posts a single event with level error or warning. The status page itself does not call your API.

Questions

What is HTTP 400?

The server could not understand the request.

Should the client retry?

Do not retry until the request changes.

Should I alert on it?

Usually no. One bad client is noise. Alert if your own service starts sending 400s.

How is this different from reading the spec?

The page adds a plain retry note and an alert verdict for people running the service, not only for people parsing the response.