Skip to content

Debugging 404 Missing Resources

A 404 means the URL the replay sent doesn't exist on the server. The most common cause is a URL containing a dynamic value (product ID, session ID, file hash, order number) that wasn't extracted from a previous response, so the test case is requesting the recording's stale value instead of a fresh one. Other causes: the resource was actually deleted between the recording and the replay, or the test case points to the wrong environment entirely.

This is one of the textbook unconfigured dynamic field failure modes, just located in the URL path instead of in form-field data.

Symptom

Visual indicators:

  • Replay View: Failed transaction shows 404 status code
  • Content View: Response shows "Page Not Found" or "404 Error"
  • Headers View: Request URL contains values (IDs, tokens, filenames) that look session-specific

Example failure sequence:

✓ GET /products (200 OK) - Product list loads successfully
✓ GET /products/123 (200 OK) - Product details for ID=123 loads on first replay
❌ GET /products/123 (404 Not Found) - Same hardcoded URL fails on subsequent replays

The give-away: the recorded URL contained /products/123, but on the live system there's no longer a product with ID 123 (it was test data, or the IDs rotate, or the recording session created data that's since been cleaned up).

Diagnostic Steps

Step 1: Identify dynamic-looking segments in the URL

  1. Open Headers View for the failed 404 transaction
  2. Look at the request URL for path or query-parameter values that look session-specific:
    • Numeric IDs: /products/123, /orders/45678
    • UUIDs / hashes: /files/a7b3c2d1-4e1d-...
    • Tokens: /sessions/abc123xyz
    • Timestamps: /cache/20260208153045
  3. Look at a previous transaction (the one that would naturally produce that value, like a list page that linked to the missing detail page)
  4. Search the previous transaction's response for the dynamic value. If you find it, that's where an extractor needs to live.

Step 2: Decide what category the failure is in

Solutions

Fix 1: Extract the URL Value

Re-run the Configure for Replay wizard (or ASM standalone if hostnames are already restricted). ASM detects most dynamic URL segments automatically, especially UUIDs and Next.js-style hashes.

If ASM still doesn't catch it, the URL value probably uses a non-standard pattern that the built-in rules don't recognize. Create a custom extractor on the response that contains the value, then configure a URL modifier on the failing transaction to substitute the extracted variable into the URL path.

Fix 2: Refresh Test Data

If the URL value is correct but the resource is gone, the test data was cleaned up between recording and replay. Two options:

  • Re-record with current test data. Quickest fix when the recording is recent and you can re-do the workflow.
  • Restore the test data in the environment (coordinate with operations or development). Useful when re-recording is expensive and the data should logically still exist.

Fix 3: Check the Base URL

If lots of transactions are 404'ing and the base URL itself looks wrong (dev.example.com vs staging.example.com), the test case is pointing at the wrong environment.

  1. Open the test case in Test Case Editor
  2. Right-click the first transaction → Edit
  3. Change the hostname to the correct environment
  4. Run replay again

For a full hostname rewrite across many transactions, see Modifying Test Case Content.

Still Failing?

Ask the AI

Replay fails with 404 on /products/123. I can see /products/123 in the
recording but not on the live server. Is this a stale test data problem
or did ASM miss extracting a dynamic product ID?

The AI can compare the recorded and replayed URLs, look back through previous responses for the value, and tell you whether to fix the test case or fix the data.