Skip to content

Understanding Replay Results

A successful replay proves your test case is configured correctly and ready for load testing. This guide explains what replay results show, how to interpret success and failure indicators, and when your test case is ready to scale up.

Why replay results matter: Replay is your quality gate before load testing. A failing replay means virtual users will fail during load testing, wasting your time and (if you're using cloud engines) your money. A successful replay means the test case correctly simulates user behavior and can scale to hundreds or thousands of virtual users.

What Replay Results Show

When you run a replay, Load Tester executes the test case as a single virtual user and reports the outcome for every HTTP transaction (request/response pair). The results tell you whether each transaction succeeded, what HTTP status the server returned, how long each transaction took, and whether the response contained the content you expected.

Where to see results:

  • Replay View: Live transaction-by-transaction status during replay (primary interface)
  • Test Case Editor: Visual indicators (green/red) next to each page and transaction
  • Content View: Actual HTTP response content (HTML, JSON, images) for each transaction
  • Headers View: Complete HTTP headers (request and response) for debugging

Success and Failure Indicators

Load Tester uses color-coded visual indicators throughout the UI to show replay status at a glance.

Green = Success

What it means: The transaction completed successfully with expected results.

Technical definition:

  • HTTP status code is in the "success" range (typically 200-299)
  • Response contains expected content (no validation errors)
  • No network errors (timeouts, connection refused)

Visual indicators:

  • Replay View: Transaction row shows green checkmark (✓) icon
  • Test Case Editor: Page/transaction shows green indicator in the tree
  • Status View: Overall replay status shows "Completed successfully"

What to do: Nothing. This is the goal. When all transactions show green, the replay succeeded.

Red = Failure

What it means: The transaction failed and virtual users would fail at this point during load testing.

Technical definition:

  • HTTP status code indicates error (400-499 client errors, 500-599 server errors)
  • Network error (connection refused, timeout, DNS failure)
  • Validation error (expected content not found in response)
  • ASM correlation error (dynamic field value couldn't be extracted)

Visual indicators:

  • Replay View: Transaction row shows red X icon
  • Test Case Editor: Page/transaction shows red indicator in the tree
  • Status View: Overall replay status shows "Failed" with error count

What to do: Investigate and fix before load testing. Every red transaction in replay becomes hundreds of red transactions under load. See Debugging Failed Replays for systematic troubleshooting.

HTTP Status Codes and What They Mean

HTTP status codes are three-digit numbers the server sends to indicate the result of each request. Load Tester interprets these codes to determine success/failure.

2xx Success Codes (Green)

Code Meaning What It Means For Your Test
200 OK Standard success response Perfect: server processed the request and returned content
201 Created Resource created successfully Common for POST requests that create data (e.g., submitting a form)
204 No Content Success, but no response body Normal for some operations (e.g., DELETE requests)

Action: None needed. These are successful transactions.

3xx Redirection Codes

Code Meaning What It Means For Your Test
301 Moved Permanently Resource moved to a new URL permanently Load Tester follows the redirect automatically. Investigate if the recording didn't redirect here, since application behavior may have changed.
302 Found (Temporary Redirect) Resource temporarily at a different URL Load Tester follows the redirect. Common for login flows.
304 Not Modified Cached content is still valid Normal: browser (or Load Tester) can use cached copy

Action: Redirects don't fail the transaction by themselves. If a page redirects during replay but didn't during recording, investigate why the application behavior changed before scaling to a load test.

4xx Client Error Codes (Red Failure)

Code Meaning What It Means For Your Test
400 Bad Request Server couldn't understand the request Likely cause: ASM didn't configure a dynamic field correctly, or request syntax is wrong
401 Unauthorized Authentication required or failed Likely cause: Session expired, login credentials wrong, or authentication not configured
403 Forbidden Server understood request but refuses to fulfill it Likely cause: Permissions issue, CSRF token missing, or session security check failed
404 Not Found Requested resource doesn't exist Likely cause: URL contains dynamic value that wasn't extracted, or server removed the resource
405 Method Not Allowed HTTP method (GET/POST/PUT/DELETE) not supported Likely cause: Application changed and now requires a different method
409 Conflict Request conflicts with current server state Likely cause: Trying to create duplicate data, or timing issue
429 Too Many Requests Rate limiting triggered Likely cause: Replaying too fast, or server has strict rate limits

Action: These are configuration errors, and you must fix them before load testing. Running a load test with 4xx errors is like rehearsing a play where the lead actor keeps falling off the stage. See Debugging Failed Replays for step-by-step troubleshooting.

5xx Server Error Codes (Red Failure)

Code Meaning What It Means For Your Test
500 Internal Server Error Generic server-side error Likely cause: Application bug, database issue, or server misconfiguration. Not usually a test case problem.
502 Bad Gateway Proxy/load balancer received invalid response from upstream server Likely cause: Backend server down or misconfigured
503 Service Unavailable Server temporarily can't handle requests (overloaded or down) Likely cause: Server maintenance, overload, or deployment in progress
504 Gateway Timeout Proxy/load balancer didn't receive timely response from upstream server Likely cause: Backend server very slow or unresponsive

Action: 5xx errors are usually server-side problems, not test case configuration errors. That said, if they appear during replay, they will absolutely appear during load testing. Retry the replay to see if the error is reproducible. If it is consistent, coordinate with the development or operations team to fix the server issue before you spend time (and potentially money) on a load test that will only confirm what you already know.

Interpreting Replay View Results

The Replay View shows transaction-by-transaction results in real time during replay. Here's how to interpret what you see:

Transaction List (Main Table)

Each row represents one HTTP transaction. Columns show:

Column What It Shows How to Interpret
Status Icon Green checkmark or red X Quick visual summary: scan for red
Transaction Name URL or transaction label Identifies which request failed
Status Code HTTP status code (200, 404, 500, etc.) Detailed success/failure reason (see tables above)
Response Time Time to complete this transaction (milliseconds) Performance indicator: unusually slow responses may indicate issues
Content Length Size of the response body (bytes) Data validation: unexpected sizes may indicate wrong content

How to use it: Scan the Status Icon column for red indicators. If you see red, click the row to see error details in the lower panel. All green means the replay succeeded and you're ready for load testing.

Error Details Panel (Bottom)

When you click a failed (red) transaction, the bottom panel shows why it failed:

Common error messages:

Error Message What It Means How to Fix
"Assertion failed: expected content not found" Response didn't contain expected text or value Check if application changed, or adjust validation rules
"Field value not found: fieldName" ASM couldn't extract a dynamic field value from a previous response Re-run ASM wizard to configure the field source
"Connection refused" Server isn't running or firewall is blocking Verify server is accessible at the URL
"Read timed out" Server took too long to respond Increase timeout settings, or investigate why server is slow
"401 Unauthorized: Authentication required" Session expired or login not configured Configure authentication (Basic/OAuth/certificates)

When Is Replay "Successful"?

A replay is successful when ALL of these conditions are met:

  1. ✅ All transactions show green (no red failures)
  2. ✅ HTTP status codes are expected (mostly 200 OK, expected redirects)
  3. ✅ Response times are reasonable (similar to recording, not dramatically slower)
  4. ✅ Content validation passes (responses contain expected data)
  5. ✅ No ASM errors (dynamic fields extracted correctly)

Replay is NOT successful if:

  • ❌ Any transactions show red (even one failure means virtual users will fail during load testing)
  • ❌ Response times are 10x slower than recording (indicates server performance problem or network issue)
  • ❌ Content is wrong even when status is green (200 OK can still wrap an error page or empty response; verify content matches expectations)

Edge case: green status with surprising content:

A transaction can return 200 OK and still contain wrong data, like an error page that the developer helpfully wrapped in a 200 response. Status indicators only check HTTP-level success. If your critical pages succeed at the HTTP level but contain the wrong content, that's a test case configured without validation rules. See Validation Rules for how to catch this class of failure before it gets to a load test.

Using Results to Verify Test Case Correctness

Replay results tell you whether your test case accurately simulates user behavior. Here's how to use them systematically:

Step 1: Run Replay and Check Overall Status

  1. Click Play (▶️) button to run the replay
  2. Watch Replay View as transactions execute
  3. Check Status View: Does it show "Completed successfully" or "Failed"?

If "Completed successfully" with all green: ✅ Proceed to Step 2 (verify data correctness)

If "Failed" with red transactions: ❌ Proceed to Debugging Failed Replays

Step 2: Verify Data Correctness

Even if all transactions are green, verify the content is correct. A transaction can return 200 OK and still contain completely wrong data, like an error page that the developer helpfully wrapped in a 200 response.

How to verify:

  1. Click on critical transactions in Replay View (e.g., login, search, checkout)
  2. View the response content in Content View (bottom panel)
  3. Check:
  4. Does the HTML/JSON contain expected data (correct username, correct search results)?
  5. Are there unexpected error messages in the response content?
  6. Does the page structure match what you expect?

Common issues: Server returns 200 OK but shows "You are not logged in" (authentication not configured correctly). Server returns 200 OK but shows empty search results (search query parameters not configured). Server returns 200 OK but shows a generic error page (dynamic field correlation failed). In each case, the HTTP status code lied to you. The content told the truth.

If data is incorrect: Reconfigure the test case (re-run ASM wizard, adjust field extractors, configure authentication).

Step 3: Compare Replay to Recording

Replay should behave similarly to the original recording. Significant differences indicate configuration problems or server changes.

What to compare:

Aspect Recording Replay What Differences Mean
HTTP status codes All 200 OK Mix of 401, 403, 404 Configuration problem: ASM or authentication not set up
Response times ~500ms per page ~5000ms per page Performance problem: server slow or network issue
Number of redirects 0 redirects 3 redirects per page Application behavior changed; verify intended
Content structure Clean HTML Error messages in HTML Functional problem: application returning errors

If replay differs significantly from recording: Investigate why the application behavior changed:

  • Did the application deploy a new version? (may require re-recording)
  • Is the test environment different from recording environment? (different server, different database)
  • Did ASM miss dynamic fields? (re-run ASM wizard)

Response Time Interpretation

Response times during replay are not load testing results. They are a sanity check that the server is responding at all, and responding in a reasonable timeframe.

What response times mean during replay:

  • Similar to recording (~100-2000ms): ✅ Normal. Server is responding as expected
  • 10x slower than recording (~10,000ms+): ⚠️ Investigate. Server may be overloaded, database slow, or network congested
  • Timeouts (30,000ms+): ❌ Problem. Server isn't responding in time (increase timeout settings or fix server)

Why response times don't predict load testing performance: Replay is one virtual user; load testing is hundreds or thousands, and concurrency changes everything. Replay runs from your workstation; load testing may run from remote engines on a different network path. And replay happens at a moment in time when the server may be under entirely different background load than it will be during the real test.

Use replay response times to verify the server is responding (not timing out), flag unusually slow transactions for investigation, and establish a rough baseline for comparison during load testing.

Don't use replay response times to predict load testing performance, make architectural decisions, or set performance goals. A single-user replay tells you almost nothing about what happens when 500 users show up at once.

Common Replay Result Patterns

Pattern 1: All Green Except Login Transaction (401 Unauthorized)

What it means: Authentication is not configured. The virtual user can't log in, so everything downstream either fails outright or "succeeds" as an anonymous session with completely wrong content.

How to fix: Configure authentication using Basic/Form Authentication, OAuth & Bearer Tokens, or Client Certificates.

Pattern 2: First Few Transactions Green, Then All Red

What it means: Session expired or correlation error. The test case worked initially but fell apart when it hit a dynamic field that wasn't configured. The session cookie or token from page 3 didn't make it to page 4.

How to fix: Re-run the ASM wizard to configure session tracking and dynamic fields. See Application State Management.

Pattern 3: All Green But Response Times 10x Slower

What it means: Server is slow or overloaded. Transactions succeed, but performance is degraded.

How to fix:

  • If test environment is slow: This may be expected (test servers often have fewer resources than production)
  • If production is slow: Investigate server performance (database queries, CPU, memory)
  • If network is slow: Check network path, consider using remote engines closer to the server

Pattern 4: Random Red Failures (Different Transactions Each Replay)

What it means: Intermittent server errors, timing issues, or race conditions. Something on the server side is not deterministic.

How to fix: Run replay multiple times and track which transactions fail. If it's the same one every time, that's a configuration issue (not truly intermittent). If different transactions fail each time, investigate server stability: check logs, database connections, resource limits. If the pattern is consistent in its inconsistency, you may be dealing with timing-dependent logic like session expiration or time-based tokens.

Ask the AI to Interpret Replay Results

If you're unsure what your replay results mean or why transactions are failing:

My replay shows several red failures with 403 Forbidden errors. Can you help
me understand what's causing these failures and how to fix them?

The AI can:

  • Analyze Replay View results to identify failure patterns
  • Explain HTTP status codes in the context of your application
  • Identify likely causes (ASM configuration, authentication, server errors)
  • Recommend specific fixes based on error patterns
  • Walk you through systematic debugging steps
  • Verify when replay results indicate the test case is ready for load testing

Next Steps

After verifying replay results:

For configuration fixes: