Can OpenText count peak Vusers against your license

It is the question that decides most LoadRunner findings: can a single peak Vuser figure, reached for a few minutes during one test, be treated as the standing entitlement the organization must license? The audit's preferred answer is yes, because the peak is the largest number it can point to. The defensible answer is that a momentary peak is evidence of a test, not of a permanent requirement, and the records that distinguish the two belong to the buyer.

LoadRunner is licensed by concurrent Vusers, the number that can run at the same time, and performance testing is inherently bursty. A load test pushes a high Vuser count for a short window to see how an application behaves under stress, then drops to nothing when the test ends. An audit that captures that brief spike and prices it as the sustained entitlement is reading the peak as the requirement, which overstates what the organization actually needs to run. Because the EULA makes compliance the sole responsibility of the licensee, the buyer must show the genuine concurrent requirement, and the execution data that does that, who ran what and when, is in the buyer's own test records.

Whether a peak can be charged at all

The starting point is the entitlement definition. A Vuser entitlement licenses concurrent execution, and the relevant question is the level of concurrency the organization genuinely operates at, not the single highest figure ever logged. A peak is real in the sense that it happened, but treating it as the standing entitlement assumes the organization must permanently license capacity it used once for a stress test. That assumption is what the buyer contests. The unit itself, and why concurrency rather than population governs it, is explained in what is a Vuser and how is it licensed, and the broader mechanics of how peak figures inflate a finding are set out in how Vuser counting inflates a LoadRunner finding.

The practical answer is that a peak can be charged only if the organization genuinely requires that level of concurrent capacity on a standing basis. Where the peak was a one off stress test, an experiment, or a configuration that ran briefly and was never repeated, it represents a transient event rather than an entitlement, and the buyer who can demonstrate that from the records holds the count to the sustained requirement.

How peak counting overreaches

The one off stress test

A deliberate stress test pushes load far beyond normal operating levels precisely to find the breaking point. Pricing that exploratory peak as the entitlement misreads the purpose of the test. Separating the burst from the sustained level is the work described in how to scope LoadRunner Vuser bursts.

Provisioned but unexecuted capacity

A peak can also be inferred from configuration, a Vuser pool that was defined but never fully executed, which is not even a real event, let alone a standing requirement. The defensible count rests on what ran, not on what a configuration file allowed.

Aggregated peaks across tests

Summing the peaks of separate tests that never ran together produces a figure no single moment ever reached. The genuine requirement is the highest level of true simultaneous execution, and the evidence for it is assembled as in reducing a LoadRunner finding with concurrency evidence.

How we answer the peak question under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. We take the single controlled channel and preserve the controller logs, scenario results, and load generator data, because the peak argument depends entirely on the granular execution record that shows what actually ran and for how long.

Reconstruct. We build the effective license position by reconstructing genuine concurrent execution, identifying which peaks were sustained operating levels and which were transient stress events, before any vendor script runs.

Rebut. We challenge every line that prices a transient peak, an inferred configuration, or an aggregate of non concurrent tests as the standing entitlement. The finding falls to the level of concurrency the organization genuinely requires.

Resolve. We settle on that reconstructed level and, where it serves the buyer, convert forward into an OpenPass agreement that defines how concurrency is measured, so a future stress test cannot be reinterpreted as a permanent requirement.

An anonymised outcome

The reason the peak question is worth contesting hard is the remedy that follows a finding. On noncompliance the licensee is deemed to have acquired licenses at then current list price, owes back maintenance and support, owes first year maintenance on the new licenses, and reimburses the cost OpenText incurs performing the audit, so every Vuser of inflated peak carries a fourfold charge. In a recent engagement the opening figure rested on a single stress test peak; once the records showed it was an exploratory event and established the sustained operating level, the count fell to that level and the finding followed. The same separation of momentary from sustained produced our anonymised banking ArcSight result, where the finding dropped 70 percent from $6.0M to $1.8M once burst was distinguished from sustained use.

A peak is an event, not an entitlement

The lasting lesson is that a peak Vuser figure records something that happened, not something the organization must permanently license, and the buyer who holds that distinction, supported by the execution records, prevents a transient spike from setting the standing count. To understand the cost that rides on the answer, read how much does a LoadRunner Vuser finding usually cost, and to see how environments compound the same overreach, read LoadRunner environment counts and license exposure. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If a LoadRunner finding has charged a test peak as your entitlement, open a case.