Load Testing in CI/CD — WPLoadTester 7 - Web Performance
CI / CD

Load testing, already running in your pipeline.

WPLoadTester has had a command-line runner since 2011. In 7.0 we added JUnit output and pass/fail thresholds so it behaves like a first-class CI step: fail the build if p95 latency regresses, fail it if error rate spikes, show results in the same place you see unit tests.

Quick context: the CLI runner has been shipping with WPLoadTester for about 15 years — we just never marketed it. 7.0 closes that gap with threshold flags (--fail-if-*) and structured output (--junit-xml), which are what turn a runnable tool into a CI eliminator-checkbox answer.

Copy-paste CI examples

Both examples run a load test, fail the build on latency or error-rate regressions, and publish JUnit results so the CI dashboard picks them up.

GitHub Actions (.github/workflows/loadtest.yml)
name: Load Test
on: [push, workflow_dispatch]

jobs:
  loadtest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run WPLoadTester
        run: |
          wploadtester execute tests/checkout-flow.wpt \
            --users 5000 \
            --duration 10m \
            --fail-if-p95-above 2000ms \
            --fail-if-error-rate-above 1% \
            --junit-xml results.xml

      - name: Publish test results
        uses: mikepenz/action-junit-report@v4
        if: always()
        with:
          report_paths: results.xml
Jenkins (Jenkinsfile)
pipeline {
  agent any
  stages {
    stage('Load Test') {
      steps {
        sh '''
          wploadtester execute tests/checkout-flow.wpt \
            --users 5000 \
            --duration 10m \
            --fail-if-p95-above 2000ms \
            --fail-if-error-rate-above 1% \
            --junit-xml results.xml
        '''
      }
      post {
        always {
          junit 'results.xml'
        }
      }
    }
  }
}

CLI flag reference

The subset that matters in CI. Full reference ships in the WPLoadTester manual.

FlagWhat it does
execute <testfile>Run a WPLoadTester test file (.wpt) from the command line.
--users NNumber of virtual users to simulate.
--duration TTest duration, e.g. 10m, 1h.
--ramp-up TRamp-up period before steady state.
--fail-if-p95-above XmsNew in 7.0. Exit non-zero if p95 response time exceeds X. Use Xms, Xs, etc.
--fail-if-p99-above XmsNew in 7.0. Same as above for p99.
--fail-if-error-rate-above X%New in 7.0. Exit non-zero if error rate exceeds X percent.
--junit-xml <path>New in 7.0. Write results in JUnit XML for native CI display.
--json <path>New in 7.0. Write results in structured JSON for programmatic consumption.

What it looks like in your pipeline

Green when latency and error budgets hold. Red when they don't. Same signal as unit tests.

A8 — ships with 7.0 CLI

GitHub Actions run screenshot

Passing green CI run with the WPLoadTester step and JUnit threshold output visible.

A9 — ships with 7.0 CLI

Jenkins pipeline view screenshot

Pipeline stages with the WPLoadTester load-test stage and published JUnit report.

Coming in WPLoadTester 7.1: A GitHub Action in the Marketplace and a dedicated Jenkins plugin. For 7.0, the CLI approach above works with any CI system that can run a shell command and parse JUnit XML — which is all of them.

Software

Copyright © 2026 Web Performance, Inc.

A Durham web design company

×

(1) 919-845-7601 9AM-5PM EST

Complete this form and we will get back to you as soon as possible. Please note: Technical support questions should be posted to our online support system.

About You
How Many Concurrent Users