Catch the errors that don’t trip the HTTP status code.
Under a 10,000-user load test, no one is reading every response. WPLoadTester compares every replay against the recorded page automatically and flags the responses that drifted, even when the server returns a clean 200. Site-wide and per-page rules let you adapt the validation to what your application is actually supposed to look like.
Why HTTP status codes are not enough.
The HTTP specification says servers should return a 5xx status on errors. The reality is that most web applications do not. The error patterns that slip past a status-code check are common:
- 200 with an error body · the server hits an exception, catches it, and returns a friendly "something went wrong" page with status 200
- Generic redirect to an error route · the user gets a 302 to
/error, which itself returns 200 - Partial response · the server times out a downstream call and returns the page with a missing widget, no error reported
- Wrong page rendered · routing or session issue puts the user on the wrong page entirely; status 200, content nothing like expected
- Soft errors in JSON ·
{ "error": "rate limited" }at status 200, because the API designer chose to put the error in the body
A test that only checks status codes counts every one of those as a success. The user, meanwhile, sees a broken application.
What WPLoadTester compares.
For every page in a recorded test case, WPLoadTester captures the response that came back during recording. That captured response is the baseline. At replay time, the same request goes out and the actual response is compared against the baseline.
The default comparison is structural: text content, key markers, expected response length range. Volatile content that legitimately varies (timestamps, session IDs, randomized user IDs, CSRF nonces) is detected from the recording analysis and excluded from validation by default. The cases ASM cannot identify automatically can be excluded explicitly via a per-page rule.
Custom validation rules.
The default rules cover the common shapes; custom rules handle anything specific to your application.
- Site-wide rules apply to every page of the test case. Useful for "every page must contain the navigation bar" or "no page should ever contain the string
NullPointerException" - Per-page rules apply to one specific transaction. Useful for "the cart page must contain at least one line item" or "the checkout confirmation must include an order number that matches the pattern
ORD-\d+" - Required content rules assert that specific text or structural elements must be present
- Forbidden content rules fail the page when specific error markers are present
- Excluded regions tell validation to ignore content that legitimately varies across replays
From a failed page to a diagnosed cause.
When validation fails, the failure surfaces in the test results next to the failed virtual user. Opening the failure brings up the Visual Content Compare editor (shown above): the recorded baseline on one side, the actual replay response on the other, the differing region highlighted. The diagnosis is what changed, not "this page failed somehow."
Validation failures also propagate into the analytics dashboard’s Errors tab, alongside HTTP-level failures, so the report tells the full failure story. Read about the Metrics Dashboard
Run a load test that actually verifies the response.
Page validation, the Visual Content Compare editor, and custom validation rules ship in every edition of WPLoadTester 7. Request the beta to run validated tests at cloud scale, or download the free single-machine edition to evaluate locally.
Reference: the canonical validation docs live at docs.webperformance.com.