Skip to content

Debugging 405 Method Not Allowed

A 405 means the URL exists but doesn't accept the HTTP method (GET / POST / PUT / DELETE / PATCH) the test case is sending. The server deployed a new API version that changed the method, or the URL itself has migrated (the old GET endpoint became a POST endpoint, or vice versa).

Unlike most replay failures, 405 isn't usually an unconfigured dynamic field. Load Tester replays the exact method that was recorded, and if the server changed the contract, the test case has to be updated to match.

Symptom

Visual indicators:

  • Replay View: Failed transaction shows 405 status code
  • Response headers: An Allow header tells you which methods the URL does accept (e.g., Allow: GET, POST)

Solution: Re-Record the Test Case

You can't convert a recorded GET into a POST (or vice versa) through configuration, because the request body structure is fundamentally different. Re-record the test case against the current API.

If the URL change is widespread (a whole-API version bump), consider whether the load test you're updating is still the right test to run, or whether a fresh recording of the new flow is a better starting point.

Still Failing?

If you've re-recorded and still see 405, check whether the test case has any modifier rules that rewrite the method (uncommon, but possible). Otherwise, contact the application team. The server is rejecting a method it shouldn't.

Ask the AI

Replay fails with 405 Method Not Allowed on POST /api/v1/users. The Allow
header in the response says only PUT is accepted. Can I convert the
recorded POST to a PUT or do I need to re-record?