Built from 27 years of performance-engineering judgment. Human-authored rules drive the analysis, AI writes the report.
Under the WPLoadTester 7 AI Assistant is a curated decision tree. The Assistant uses it to classify a failing or degraded load test, then to drill into the specific failure signature. The tree is small, deterministic, and authored entirely by Web Performance engineers.
Each rule in the playbook was authored by a senior performance engineer from accumulated diagnostic experience. The LLM navigates the tree. It does not author the rules.
The Assistant starts at the top of the tree and commits to a route before it sees that route's diagnostic content. That commit is on purpose. It prevents the model from cherry-picking conclusions, and it produces an audit trail of how the diagnosis was reached.
Classifies the test by error rate, latency, and throughput. Routes to one of seven symptom domains. A single prompt with no parameters.
Seven domains, one per failure family the playbook covers. Each L1 page tells the Assistant what to look at next and which L2 signatures are most likely.
Concrete diagnostic conclusions for a specific pattern. The first signature, timeouts coexisting with 500 errors, ships in 7.0. The library grows with each 7.x release.
Every load test that fails or degrades does so in one of these seven shapes. The L1 layer is fully populated in WPLoadTester 7.0.
The first L2 signature in the library names a pattern any senior performance engineer recognizes on sight. When timeouts and HTTP 500 errors appear together at the same load level, they are usually one cascading failure, not two independent problems.
The upstream service slows under load. Downstream requests time out waiting for it. The downstream service then returns 500 errors because the responses it needed never arrived. Two symptoms, one root cause. The playbook tells the Assistant to look for the pairing at the same load level and treat it as a single root cause to investigate first, rather than as two unrelated findings.
More L2 signatures are being added in subsequent 7.x releases. The L0 and L1 layers are fully populated today, and the Assistant can fall back to L1 guidance whenever a specific L2 pattern is not yet authored.
Both the playbook and the AI sit downstream of a deterministic detection layer. When a test finishes, WPLoadTester runs hard-coded calculations against the data: error rates, latency percentiles, throughput inflections, the specific arithmetic that decides whether a given condition is present. These calculations are unit-tested. They produce yes/no triggers, not interpretations.
A triggered condition surfaces the matching playbook entry, which carries the human-authored diagnostic context. The AI receives both, and then does two things on top:
The principle holds across the product. Use hard code and math wherever possible, and feed those deterministic outputs into the AI to verify the conclusions and look for other relationships. The AI is never the primary source of truth for something that can be calculated.
Three properties define how the playbook contributes to the analysis, and why it accumulates over time rather than being something that can be written in a sitting.
Every rule was written by a senior performance engineer from accumulated experience diagnosing real load-test failures. The LLM navigates the tree. It does not write the rules.
Lookup is exact-string match against the level and symptom names. There is no fuzzy retrieval, no vector index, no embedding. Every routing decision the Assistant makes is logged and can be replayed.
The pattern recognition encoded in the playbook came from diagnosing the failures, not from reading about them. That kind of judgment accumulates from years of consulting engagements; the playbook is the artifact of that accumulation.
This is the layer of the AI Assistant that explains the canonical claim on the Bring Your Own AI page: the AI sits on top of a deterministic expert system battle-tested against thousands of real test cases. The playbook is one half of that expert system. The ASM correlation rules are the other.
The playbook is exposed to MCP clients as the get_triage_prompt tool on the WPLoadTester 7 MCP server. Each call returns one level of the tree along with navigation hints to the next level. If you drive WPLoadTester from Claude Code, Codex, Cursor, Windsurf, or any other MCP-compatible client, the AI in your terminal walks the same playbook the in-app Assistant uses.
Run the playbook against your own test cases.
The diagnostic playbook ships with every WPLoadTester 7 install. Request the beta and put the AI Assistant, or your favorite agentic CLI over MCP, against your existing test cases.
Comparing tiers? See the Free vs Pro split.