Accidental settings recovery for JMeter test plans

One complaint stands out as structurally different from the rest: 'Settings are too easy changeable, sometimes by mistake and it's hard to return to your desired ones.' This isn't a learning curve problem — it's an ongoing operational problem that hits experienced users too. JMeter's test plan UI makes it trivially easy to drag a listener to the wrong scope, change a sampler's timeout mid-run, or fat-finger a thread count. There's no undo history that survives a save, no audit trail of what changed between runs, and no diff view between two versions of a .jmx file that a non-technical person can read.

The reason this hasn't been fixed inside JMeter is structural: the project uses a Swing GUI built over two decades, and adding meaningful change tracking to it would require architectural work that volunteer maintainers have no incentive to prioritize when there are always more pressing feature requests. The people who feel this pain most — QA leads running regression suites under deadline pressure — don't contribute to Apache projects.

Teams currently work around this by committing .jmx files to Git, but a raw XML diff of a JMeter test plan is nearly unreadable: element order shifts, UUIDs change, and nested scoping isn't visually obvious in XML. So teams either skip version control entirely or have a senior engineer manually audit plans before each major run.

Every time a test run produces unexpected results, the first question is 'did someone change the plan?' — and right now, answering that question takes 20-40 minutes of manual XML comparison or memory. For teams running nightly performance tests, that cost recurs weekly.

What to build

Build a desktop or CLI tool that watches a directory of .jmx files, maintains a human-readable changelog (thread counts, sampler URLs, timeout values, listener scopes — not raw XML diffs), and lets a user restore any named field to a previous value without touching the raw XML.

Where to start

Target teams already using Git for .jmx files, because they've already accepted the value of version tracking — they just find the raw XML diff unusable. A Git-integrated diff renderer (a CLI command or GitHub Action that renders a .jmx diff as a structured table) gives them immediate value without changing their workflow.

The hard part

Parsing JMeter's .jmx format cleanly enough to produce a human-readable semantic diff — rather than an XML structural diff — requires reverse-engineering the element schema across multiple JMeter versions, and edge cases in nested scoping will create false positives that erode trust in the changelog.

How it makes money

Free CLI tier for individual use; $19/month per team for the hosted changelog dashboard with Slack notifications when a plan changes before a scheduled run, plus one-click restore.