Hi! First of all, thanks for building oha — it's a great tool for benchmarking.

Motivation

I'm currently using oha in a CI workflow to run performance checks before release (e.g. detecting latency regressions or drops in throughput).

The current JSON output is already useful, but it seems more optimized for raw export reporting than for automation.

In CI scenarios, we typically need to reliably extract:

• average latency
• p50 / p95 / p99 latency
• requests per second
• success / timeout rates

Right now, these values are either:

• spread across different fields
• not explicitly grouped
• or require extra parsing / transformation

Proposal

Keep the existing summary field unchanged, and introduce a new top-level metrics field designed for machine consumption.

Example:

{
  "summary": {
    "successRate": 1.0,
    "total": 1.479430043,
    "slowest": 0.653328653,
    "fastest": 0.148516069,
    "average": 0.23997832523333332,
    "requestsPerSec": 20.27807948199143
  },
  "metrics": {
    "success_rate": 1.0,
    "requests_per_sec": 20.27807948199143,
    "latency_ms": {
      "min": 148.516,
      "mean": 239.978,
      "p50": 230.000,
      "p95": 400.000,
      "p99": 653.329,
      "max": 653.329
    }
  }
}

Why a new field?

To keep backward compatibility.

Existing users can continue using summary, while metrics provides a more structured and CI-friendly format for downstream tooling.

From a schema evolution perspective, this would be an additive (non-breaking) change.

Use case

A typical CI workflow:
1. Run oha in CI
2. Save JSON output
3. Compare against a baseline
4. Fail if:
• latency_ms.p95 increases significantly
• requests_per_sec drops
• success_rate decreases

Having a dedicated metrics field would make this much easier and more reliable.

Scope

This proposal does NOT aim to add CI logic into oha. It only focuses on improving the JSON output structure for automation use cases.

Happy to contribute a PR if this direction makes sense 🙂