Failure Diagnosis

Failure Diagnosis is now available in Gatling Enterprise Edition. Built from the most common failure patterns our team has seen across years of Gatling runs, it automatically reads a broken run and surfaces exactly what happened and how to fix it, right on the run page.

It runs on a decision tree, not a model. That means it works independently of Gatling's AI features, so every organization gets it, whether or not AI features are enabled on your account.

‍

Deterministic, instant, and available to everyone.

‍

‍

How it works

A run breaks: Gatling Enterprise Edition classifies every run status (Build Failed, Empty Feeders, Timeout, and so on). Failure Diagnosis kicks in automatically the moment that status indicates a failure.

Logs are analyzed at the source: Depending on the failure type, Gatling reads the right log stream: control plane logs for build failures, load generator logs for crashes, timeouts, and metric limits.

The failure is matched against known patterns: A growing library of recurring, real-world failure signatures, built from years of debugging Gatling runs, from a missing Git branch to an empty feeder to a duplicate scenario name.‍

‍You get the root cause immediately: When a match is found, the run page shows what happened, in plain language, and what to do next.

‍
The failure families it catches

Failure Diagnosis currently covers four broad categories of run failure.

‍

Build failures
Your simulation didn't even make it to running. Covered cases include a Git repository that couldn't be cloned (bad URL, missing branch, or credentials issue), a simulation class that couldn't be found in your package, a Kotlin version incompatible with the Control Plane's JDK, and compilation errors across every supported build tool, Maven, Gradle, and sbt for Java, Kotlin, and Scala, plus the JavaScript/esbuild toolchain.

‍

Broken runs
Your simulation started, then crashed or hit a limit. This is the largest family, and includes: too many unique request, group, or scenario metrics (usually caused by dynamic values leaking into metric names), empty or missing feeders, duplicate scenario names, a deliberate crashLoadGenerator() call, a Java class file compiled with too recent a JDK, accidental Scala 3 usage, and missing files or resources read from the filesystem instead of the classpath. For anything else, we walk the stack trace to find the first frame that's actually your code, so you know exactly where to look.

‍

Credits and duration
Two direct, unambiguous cases: your organization ran out of credits mid-run, or the run hit Gatling's 7-day maximum duration and was automatically stopped.

‍

Timeouts
When a load generator stops sending stats, usually a sign of CPU, connection, or bandwidth starvation, or a transient network issue, we flag it as a stats timeout, so you immediately know where to look instead of starting from scratch.

‍

What's next

This is a first version, built to grow. Every new recurring failure pattern we identify gets added to the library, continuously encoding years of Gatling debugging expertise directly into the product. Got feedback or a failure case you'd like to see covered? We want to hear it.