Skip to content

Debugging 500 Server Errors

A 500 response means the server crashed or hit an unhandled exception. This is not a test case configuration problem. No amount of ASM tuning, extractor work, or authentication setup will fix a server-side null pointer exception or a missing database connection. The server is broken.

That said, 500 errors during a load test are valuable findings. They're the kind of bug that production users will eventually hit, and finding them in a controlled test is literally the point of the exercise.

Symptom

Visual indicators:

  • Replay View: Failed transaction shows 500 status code
  • Content View: Response shows a stack trace, "Internal Server Error", or a generic error page

What to Do

  1. Reproduce. Run the replay again to confirm the 500 is consistent and not a transient blip.
  2. Capture the evidence. From the Headers View, copy the full request: URL, method, headers, body. From the Content View, copy whatever the server returned (often a stack trace).
  3. Hand it to the development team. Include the request, the response, and ideally a server-side timestamp so they can correlate against application logs.
  4. Wait for the fix. Run the replay again after the fix is deployed.

When 500 Errors Cascade

If many transactions return 500 at high virtual-user counts but only some at low counts, that's a capacity or resource-exhaustion issue. Common cases:

  • Database connection pool exhausted at high concurrency
  • A downstream service rate-limiting your application
  • Memory pressure leading to slow garbage collection and timeouts that surface as 500s

These are exactly the kind of finding load testing exists to surface. Run the server monitoring alongside the load test to correlate the 500 spike against CPU, memory, and database metrics.

Still Stuck?

Ask the AI

My replay returns 500 on POST /api/checkout. The response includes a
NullPointerException stack trace. Is there anything I can change in
the test case configuration that would fix this, or is this purely
a server-side bug?

(Spoiler: it's purely server-side. But it's worth confirming the test case isn't sending malformed input the server can't handle. Sometimes a 400 should have been returned and the server bug is that it crashed instead.)