Trend Reports: Stop Comparing Load Test Results in Spreadsheets
This post is the second in our "Features Sitting Idle" series, where we explore key OctoPerf features that are either misused, misunderstood, or simply unknown to most users.
"Sprint Done. Has Your Performance Regressed Since the Last Release?"¶
The question comes up every iteration, and yet teams usually handle it the same way: export two reports, open a spreadsheet, and compare numbers manually.
It works, but it doesn't scale. After three or four sprints, no one wants to open another spreadsheet.
The Patterns We See in Support¶
A few recurring patterns come up regularly in our support conversations:
- Automated tests, manual comparisons. Teams integrate their load tests into Jenkins or Maven but have no automated way to track whether results improved or degraded between runs. The comparison always ends up as a manual step.
- Regression archaeology. When a regression reaches production, going back through past test results to find when it first appeared means opening reports one by one.
- Missing build versions. Build versions rarely make it into the report description, making it hard to trace which version of the application was actually tested.
The result: teams that already invested in CI integration still spend hours every release on a "did it get worse?" question that should take thirty seconds.
What Trend Reports Solve¶
Trend Reports address exactly this. Aggregate up to 25 test results in a single report, define a reference test as your baseline, and OctoPerf automatically compares every new run against it.
Response times, hit rate, error rate: trends are immediately visible.
A few details that matter in practice:
- Auto-update. The latest results are automatically loaded each time you open the report. No manual steps, no "refresh" button, no rebuilding the layout.
- Protected baseline. The reference test is protected from automatic deletion as long as it's used in a Trend Report. Your baseline is always available, even months later.
- Native to the report engine. Trend Reports live in the same place as your regular reports. No external dashboard to maintain.
Where Trend Reports Really Shine: CI/CD¶
Trend Reports are particularly useful in CI/CD pipelines. Triggered from Jenkins or Maven, each test automatically enriches your trend history.
A typical setup:
- A scheduled or PR-triggered load test runs from Jenkins via the OctoPerf plugin.
- The result lands in OctoPerf with the build number injected in the description.
- The Trend Report picks it up automatically on the next open.
- The team has a one-page view of "are we still on track?" every Monday morning.
No CSV exports. No copy-paste into a Confluence page. No "I'll send you the comparison later".
A Quick Tip on Naming¶
A Trend Report is only as useful as the data feeding it. Two quick conventions go a long way:
- Inject the build version into the test description. Use the API or the CI plugin parameters. It takes five minutes to set up and saves hours later.
- Standardize the test name. "Smoke - login - main" is better than "test - copy - 2026 - final".
If you've never adopted these conventions, the existing Trend Reports in your account are probably noisier than they need to be.
Final Reflection¶
The performance team's value is measured by the questions it can answer quickly. "Did this release regress?" is one of those questions. If the answer takes more than a glance, the loop with the dev team breaks.
Trend Reports turn that loop from days back into seconds.
Full documentation: api.octoperf.com/doc/analysis/trend-bench-results/