Jenkins Plugin integration

The QRebel Jenkins plugin helps you automate performance testing in your CI/CD pipeline and fail builds based on the QRebel issue detection engine.

Getting the QRebel Jenkins plugin

The plugin is OSS and available for download at the Jenkins Plugin Index.


The QRebel Jenkins plugin enables teams to set up three different performance regression quality gates and one app-specific SLA gate, all of which can mark builds as unstable in Jenkins. The four gates are:

  1. Slow request regressions

  2. Excessive IO regressions

  3. Exceptions regressions

  4. App-specific SLA limit exceeded

The first three on the list all work by means of comparing the profiled code performance of the current test run against a baseline build that you as the user can specify. Number four on the list, on the other hand, relies only on the performance of the current test run and is used to ensure that a app-specific SLA policy for all tested requests is met. In case the plugin detects at least one performance issue, it marks the build unstable and prints an overview of performance analysis. For example:

Build failed because QRebel found regressions in petclinic
 build: 1.4.0rc2
 version: 1.4.0
 build: 1.4.0rc1
 version: 1.4.0
Slow Requests: 0
Excessive IO: 0
Exceptions: 5
For full report check your dashboard.


In a given Jenkins test job, you can easily hook in the QRebel regression detection to setup a performance gateway. After installing the QRebel Jenkins plugin, in the configuration part under the post-build Actions section you’ll be able to add QRebel to your job. The configuration will look like this:


You’ll need to fill in the fields as follows:

  • Application name – this is the application name as shown on your QRebel dashboard for the current app you wish to monitor. The name is case sensitive.

  • QRebel API Token – you’ll find the project-specific API token from the settings menu on your QRebel dashboard.

  • Build name – the name of the build name for which the current test run sends data to the QRebel dashboard. It’s recommended to use parameterized builds like shown above. Please note that you must specify a user-defined build name, unnamed builds are not supported.

  • Build version (optional) – the version of the build if applicable.

There are three types of comparison strategies:

  • Comparing against a baseline build name and version that you can specify in the input fields.

  • Comparing against the build that is currently set as the default baseline.

  • Comparing against a static SLA threshold which is defined in settings on the QRebel dashboard

Lastly, you need to select which type of issues you want to monitor. The three types are:

  • Slow requests

  • Excessive IO

  • Exceptions

Once done apply the configuration changes.

In case you have set up a parameterized build, start the Jenkins job by providing the input values as set up in the configuration.

Run the job and QRebel will fail the build automatically should any performance issues have been detected during the tests. Have fun!