2xx Success · RFC 9110 §15.3.1

200 OK

The request succeeded and the response carries the result.

What 200 means

The default success code. For GET it means the body is the resource; for POST it means the action ran and the body describes the outcome.

A 200 with an error message inside the JSON body is a common anti-pattern that hides failures from monitoring, load balancers and retry logic. Use 4xx and 5xx codes for failures.

Common causes

  • Normal successful request.

How to fix it

  • Nothing to fix. If clients complain the "200" is wrong, check for error payloads returned with a 200 status.

What it looks like

A typical response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 27

{"status":"ok","items":[]}

The same event in an nginx access log (the status is the number after the request line):

203.0.113.7 - - [10/Sep/2026:10:12:01 +0000] "GET /api/orders HTTP/1.1" 200 153 "-" "Mozilla/5.0"

Check it with curl

-i prints the status line and headers, and -w '%{http_code}' prints only the number, which is handy in scripts and health checks. Replace the URL with yours:

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/api/orders

Compare what curl sees with what the browser sees. A different status from the same URL usually means a cache, a CDN edge or a cookie is in the way.

Investigating a run of 200s? Paste the log excerpt into Log Share to get line numbers, highlighting and an expiring link for whoever is on call with you.

  • 201Created: The request created a new resource, identified by the Location header.
  • 204No Content: Success, and there is deliberately no response body.
  • 304Not Modified: The cached copy is still valid; no body is sent.

FAQ

Should a POST return 200 or 201?

201 when a new resource was created and can be addressed (include a Location header); 200 when the action ran but did not create a resource, such as a search or a calculation.