skip to content

After a Gatling Community Edition run, which outputs may a pipeline legitimately build on, and which file must it not parse?

level: seniorimportance: nice to knowfreq 42%

answer

  1. Exit status is the contract
  2. The report is for people to read
  3. The raw log is an implementation detail
  4. Console and file writers only

basics

~20 s

A pipeline may build on the process exit status, the static HTML report and the console writer's periodic output. It must not parse simulation.log: Gatling's FAQ answers whether you can parse it with a flat no, because its format is undocumented and can change at any time.

solid answer

~40 s

Community Edition gives a pipeline three things it may rely on: the launcher's **exit status**, which carries the verdict; the **static HTML report** generated at the end of the run, which is for humans to read; and the **console** writer's periodic statistics on standard output, useful for a live tail in a job log. The one thing it must not build on is `simulation.log`, the file writer's raw output. Gatling's own FAQ asks whether you can parse it yourself and answers “No” — it is an implementation detail whose sole purpose is generating those HTML reports, its format is undocumented, and it can change without notice. Nothing else is on offer: the run's data writers accept only `console` and `file`.

go deeper

for a junior

Be ready to say where a run leaves its output and that the HTML report is meant to be read rather than parsed.

for a middle

Be ready to name the exit status as the machine-readable result and to explain why the raw log is not one, using the documented reasons.

for a senior

Be ready to design what a pipeline archives and publishes given that contract, and to say what you would build yourself for cross-run trending.

for a principal

Be ready to decide whether a narrow output contract is acceptable for your organisation, and to price the reporting layer you would have to own or buy alongside it.

When a team compares load generators, "what can my pipeline actually consume from a run" is one of the questions that changes the answer, because it decides whether run results can be trended, alerted on and compared over months, or whether each run is a self-contained artifact a person has to open. ## What Community Edition emits | Output | What it is | Safe for a pipeline to build on | |---|---|---| | Process exit status | the run's verdict, produced by the assertions | **Yes** — this is the integration surface | | Static HTML report | generated at the end of the run, for a reader | **Yes**, as an archived artifact to open later | | Console output | periodic run statistics written to standard output | **Yes**, as a live tail in the job log | | `simulation.log` | the file writer's raw record behind the HTML report | **No** — explicitly not an integration surface | The set of writers is closed. The run's configuration accepts `console` and `file` and nothing else, so there is no built-in path that streams a run's metrics to a time-series backend or a dashboard while it happens — the Graphite writer that once offered that was dropped in 3.12. Real-time dashboards and centralised result management are what the Enterprise product adds; the Community Edition run's story ends with a directory on disk. ## Why `simulation.log` is off limits It is tempting, because it is right there and it clearly contains everything. Gatling's FAQ addresses it directly and the answer is one word: **No.** The stated reasons are worth repeating verbatim in an interview because they are the reasons that apply to any undocumented internal file: * Its **sole purpose** is generating the official HTML reports. * Its format is **not documented**. * It is **subject to change at any time** without notice. Two more measured facts complete the picture. The report generator can be pointed back at an existing log to regenerate reports from a truncated run, which is what the file is genuinely for; and the component that writes it **buffers**, so a run you forcefully interrupt loses its tail. A parser built on it is therefore reading an undocumented format that may also be incomplete. Gatling has also removed the machine-readable files people used to reach for. `stats.json`, `global_stats.json` and `assertions.xml` were deleted in 3.13.5 as dead internals, and `assertions.json` had been deleted earlier, in 3.10.0. The FAQ says plainly that they lost their purpose and will not be restored. So the absence of a parseable artifact is a deliberate position, not a gap waiting to be filled. ## What this costs, and what to do about it The practical consequences for a team standardising on Community Edition: 1. **Cross-run trending is yours to build.** If you want p95 over the last thirty nightly runs on a chart, nothing in the run produces it. You either publish the numbers yourself from something you control, or you accept per-run reports only. 2. **The verdict is the only machine-readable result.** A pipeline can know pass or fail. It cannot know by how much unless a human opens the report — so the pass rule has to carry all the precision you need, because it is the whole of the machine-readable output. 3. **Several machines mean several results.** Community Edition does not support running one profile across multiple load generators; that is an Enterprise capability. Running the same simulation on several boxes gives you several independent runs, each with its own report and its own verdict, and merging them is not something the tool does for you. ## Answering it well State the boundary as a rule rather than a list: **the exit status is the contract, the HTML report is for people, and the raw log is an implementation detail.** Then give the evidence — the FAQ's flat "No", the undocumented and changeable format, the buffered writer, and the deliberately deleted JSON and XML files. A candidate who volunteers that the removed machine-readable artifacts are not coming back has understood the position rather than memorised a page. The mature version of this answer does not treat it as a flaw. It is a narrow, honest contract: the tool promises a verdict and a human-readable report, and refuses to promise a data format it would then have to keep stable. Knowing that up front is what lets you budget for the reporting layer instead of discovering halfway through that you were building on sand.

  • Your team wants a chart of p95 across nightly runs. What are the honest options on Community Edition?
    Publish the numbers from something you control rather than from the run's own files: have the pipeline record the figures it cares about after each run, or drive the same measurements from a system that already collects metrics. What you should not do is parse the raw log, because its format is undocumented and can change under you between versions.
  • A job kills a Gatling run after a timeout and the report looks short. Why?
    The component that writes the raw log buffers, so a forcefully interrupted run loses whatever had not been flushed. The reports can be regenerated from a truncated log, but the missing tail is genuinely missing — which is a good reason to bound a run's duration inside the simulation rather than by killing the process.
  • Why did Gatling delete the JSON and XML result files rather than document them?
    Because they were internal components that had lost their purpose, and the project's stated position is that they will not be restored. Documenting them would have converted an implementation detail into a compatibility promise. The narrower contract — a verdict plus a human-readable report — is one the project is willing to keep.

saying these in an interview costs you the question

  • Building a results parser on simulation.log because it contains everything
  • Expecting a stats.json or assertions.xml alongside the report
  • Assuming the run can stream metrics to a dashboard as it goes
  • Merging several machines' reports as if the tool aggregated them