Skip to content

Common Error Messages

This page catalogs error messages you might encounter, organized by when they appear (recording, replaying, load testing). Use Ctrl+F to search for the exact error message text you're seeing.

For detailed troubleshooting workflows, see:

Recording Errors

"Unable to start recording: port 8888 already in use"

When: Starting a new recording

Cause: Another application (or previous Load Tester instance) is using the proxy port

Solution: 1. Check for other proxy applications (Fiddler, Charles, Burp Suite) 2. Kill any orphaned Load Tester processes (Task Manager → End Process) 3. Change proxy port: Tools → Preferences → Recording → Proxy Port (try 8889 or 9000) 4. Restart Load Tester

"Browser did not send any requests"

When: Stopped recording but test case is empty

Cause: Browser wasn't configured to use Load Tester's proxy

Solution: 1. Check browser proxy settings - must point to localhost:8888 2. Use the built-in browser - Let Load Tester launch Chrome automatically (easier than manual proxy config) 3. Verify proxy is running - Load Tester should show "Recording..." status

See: Browser Configuration

"SSL certificate not trusted"

When: Recording HTTPS sites, browser shows security warning

Cause: v7.0 uses a Chrome extension (not a proxy), so SSL warnings shouldn't occur. If you see this, you're likely using an older configuration method.

Solution: - v7.0: Use the Chrome extension recorder (no SSL certificate needed) - v6.0 and earlier: Accept the SSL certificate in browser

See: Recording Settings

Replay Errors

"401 Unauthorized"

When: Replaying test case, transactions fail with 401

Cause: Authentication credentials missing or session expired

Solution: 1. Check authentication setup: Verify username/password in Actors View 2. Run ASM wizard: May need to configure session tokens or authentication headers 3. Check for expiring tokens: OAuth/Bearer tokens may need refresh logic

See: Authentication, OAuth & Bearer Tokens

"403 Forbidden"

When: Replay fails with 403

Cause: Server rejected request due to: - Missing or invalid CSRF tokens - Incorrect authentication headers - IP-based restrictions (server expects different IP)

Solution: 1. Run ASM wizard - Configure CSRF tokens as dynamic fields 2. Check session cookies - May need to extract session ID from login response 3. Verify IP whitelisting - If server restricts by IP, you may need to test from allowed IP range

See: Application State Management

"404 Not Found"

When: Replay fails, transactions return 404

Cause: URLs contain dynamic IDs that changed between recording and replay

Solution: 1. Run ASM wizard - Look for session IDs, timestamp parameters, or unique IDs in URLs 2. Check for redirect changes - Server may redirect to different URLs based on session state 3. Verify base URL - Hostname may have changed (recorded from dev.example.com, replaying against test.example.com)

See: Debugging Failed Replays

"Correlation error: Could not find expected value"

When: Replay fails with correlation error message

Cause: ASM expected to extract a value (session ID, CSRF token) but couldn't find it in server response

Solution: 1. Check the transaction that failed - Error View shows which page/transaction failed 2. Review extractor configuration - Fields View → find the extractor → check boundary strings 3. Check server response - Headers View or Content View → verify the value actually exists in response 4. Adjust extractors - Boundary strings may need updating if server HTML changed

See: Boundary Extraction

"Page content validation failed"

When: Replay completes but validation shows unexpected content

Cause: Server returned different content than expected (error page, login redirect, empty response)

Solution: 1. Check Content View - Compare recorded vs. replayed response 2. Look for error messages - Server may have returned 200 OK but with error content 3. Check for redirects - Server may redirect to login page (session expired) 4. Verify dynamic field configuration - Missing correlation may cause server to reject request silently

"Connection refused" (during replay)

When: Replay fails immediately with connection refused

Cause: Server is down, firewall is blocking the connection, or hostname/port is incorrect

Solution: 1. Verify server is running - Try accessing in browser 2. Check hostname/port - Test Case Properties → verify target server 3. Check firewall - May need to allow outbound connections from Load Tester 4. VPN required? - Some environments require VPN to access test servers

Load Test Errors

"Unable to connect to load engine"

When: Starting load test, engine shows "connection refused"

Cause: Cloud engine not started, firewall blocking ports 1099 and 1100, or wrong IP address

Solution: 1. Check engine status - AWS console → verify EC2 instance is running 2. Verify IP address - Engines View → check IP matches EC2 instance 3. Check firewall rules - Must allow TCP ports 1099 and 1100 4. Wait for engine startup - Engines take 2-3 minutes to fully start after EC2 launch

See: Cloud Load Testing

"Engine startup timeout"

When: Load test won't start, engine times out

Cause: Engine didn't respond within timeout period (network issue, engine overloaded, or crashed)

Solution: 1. Check engine logs - SSH into engine, check /var/log/wpi-engine.log 2. Restart engine - Stop and restart EC2 instance 3. Check network connectivity - Ping engine from Load Tester workstation 4. Increase timeout - Tools → Preferences → Engines → Startup Timeout

"Insufficient engine capacity"

When: Configuring load test, error about VU capacity

Cause: Trying to run more VUs than engines can handle

Solution: 1. Add more engines - Each engine handles ~500-1000 VUs depending on test complexity 2. Use larger instance types - Switch from t3.medium to c5.xlarge for more capacity 3. Reduce VU count - Start with lower load, add engines as needed

See: Cloud Load Testing

"Test case upload failed"

When: Starting load test, test case won't upload to engines

Cause: Network timeout, test case too large, or engine disk full

Solution: 1. Check test case size - Very large datasets can cause upload timeouts 2. Reduce dataset size - Split large datasets across multiple test cases 3. Check engine disk space - SSH to engine, run df -h 4. Retry upload - Temporary network glitches can cause this

"Connection pool exhausted"

When: Load test running, errors about connection pool

Cause: Test case creates too many concurrent connections (each VU may open 6+ connections)

Solution: 1. Increase OS connection limits - Engines View → Advanced → Tune OS parameters 2. Add keep-alive headers - Reuse HTTP connections instead of creating new ones 3. Reduce VU ramp-up rate - Slower ramp-up gives connections time to close 4. Check TIME_WAIT sockets - netstat -an | grep TIME_WAIT | wc -l on engine

Cloud & AWS Errors

"AWS credentials invalid"

When: Configuring cloud engines

Cause: Access Key ID or Secret Access Key incorrect or expired

Solution: 1. Verify credentials - AWS IAM Console → Users → Security Credentials 2. Check IAM permissions - User must have EC2 permissions (launch instances, describe, terminate) 3. Regenerate keys - Create new Access Key if old one expired

See: Cloud Load Testing

"Insufficient capacity in availability zone"

When: Starting cloud engines, AWS returns capacity error

Cause: AWS temporarily out of capacity for that instance type in that AZ

Solution: 1. Try different instance type - Switch from c5.xlarge to c5.2xlarge 2. Try different region - us-east-1 → us-west-2 3. Wait and retry - Capacity issues are often temporary (minutes to hours)

"Request limit exceeded"

When: Starting many engines at once

Cause: AWS API rate limit exceeded

Solution: 1. Start engines in smaller batches - Launch 5-10 at a time instead of 50 2. Wait between batches - 30 second delay between launches 3. Request limit increase - AWS Support → request higher EC2 API limits

Server Monitoring Errors

"Agent connection refused"

When: Load test running, server monitoring agent won't connect

Cause: Agent not running, firewall blocking ports, or wrong IP address

Solution: 1. Verify agent is running - SSH to server, check ps aux | grep ServerMonitor 2. Check port 1099 - netstat -an | grep 1099 3. Check firewall - Allow TCP 1099/1100 from Load Tester to server 4. Use manual stats collection - Collect stats files instead of live connection

See: Monitoring Through Firewalls

Analysis Errors

"Cannot open test results: file corrupted"

When: Opening test results, error about corruption

Cause: Test results file (.wpt) corrupted, typically from disk full during test, a crash, or power loss

Solution: 1. Try backup file - Load Tester creates .wpt.backup files automatically 2. Check disk space - Ensure drive has space (test results can be large) 3. Export partial results - Right-click → Export → choose format 4. Contact support - We may be able to recover partial data

"Out of memory while generating report"

When: Opening load test results or generating reports

Cause: Test results too large for available RAM

Solution: 1. Increase Java heap - Edit LoadTester.ini, add -Xmx4g (4GB heap) 2. Close other applications - Free up RAM 3. Export subsets - Export results in chunks (first 10 minutes, next 10 minutes) 4. Upgrade RAM - Large tests (hours long, many VUs) require 8+ GB RAM

Getting Help

If your error isn't listed here:

  1. Search this documentation - Use site search for error message text
  2. Check section-specific troubleshooting:
  3. Recording Issues
  4. Replay & Configuration Issues
  5. Load Testing Issues
  6. Contact Support - See Getting Support for how to gather diagnostic logs

When reporting errors: - Copy the exact error message text - Note when it occurs (recording, replay, load test startup, during test, etc.) - Include steps to reproduce if possible - Attach diagnostic logs (see Getting Support)