HAR Status 0 vs HTTP 500: Find Where an API Request Failed

A HAR entry may record status 0 when the capture has no normal HTTP response for that request. It can accompany a cancellation, a network failure, or limitations of the capture. It does not by itself prove that the server returned an error or that CORS is the cause.

Reproduce once with the browser's Network and Console panels open. Record the request method, URL, timestamp, browser error and whether a response header section exists. Compare a failed request with a successful request to the same service before changing server configuration.

For cross-origin requests with certain methods or headers, the browser may send an OPTIONS preflight first. If that preflight is rejected, the application POST may never run. Inspect the OPTIONS entry and the browser's CORS message together.

A server can also return a real 500 without the CORS headers needed for the browser to expose its body to JavaScript. In that case the console may mention CORS while the underlying server failure is still the first issue to investigate. Neither disabling browser security nor adding wildcard credentials is a production fix.

Look for an existing request or correlation identifier in the response headers. Search application and gateway logs for that identifier and a narrow time window. If there is no identifier, use method, path and timestamps, allowing for timezone and clock differences.

If the gateway recorded a response but the application has no matching request, investigate routing, authentication or upstream connectivity. If the application recorded a 500, inspect its exception and deployment context. Browser duration shows the observed request time, not a database execution plan.

HAR files can contain authorization headers, cookies, query values and response bodies. Use the local HAR analyzer to isolate the request and inspect it before sharing. A sanitized summary of status, method, timing and identifier is often enough for initial triage.

Verify that a proposed fix changes the same failing request: the preflight succeeds where needed, the expected application response appears, and the client can read it. A page reload that happens to work is insufficient evidence for an intermittent failure.