How VU Hours (VUH) are calculated

Understand how BrowserStack Load Testing estimates, consumes, and tracks VU Hours across adjusted virtual users, multi-engine, multi-region, hybrid, and iteration-based tests.

VU Hours (VUH) measure the compute you consume when you run load tests on BrowserStack. Your plan includes a monthly VUH quota, tracked separately for API tests (k6, JMeter, Gatling, Locust) and browser tests (Playwright, Selenium, WebdriverIO, Nightwatch). This page explains how VUH is calculated so your usage dashboard holds no surprises.

Adjusted Virtual Users

BrowserStack bills based on Adjusted Virtual Users the compute capacity reserved for your test, not just the VU count you configure.

Each API load test engine reserves a fixed capacity of 1,000 VUs, regardless of how many VUs you actually configure. An engine running 500 VUs reserves the same compute as one running 1,000 VUs — the same memory and CPU allocation. So VUH is calculated from the reserved capacity, not the configured VUs.

The formula to calculate

For API tests:

Engines       = ceil(Your VUs / 1,000)
Adjusted VUs  = Engines × 1,000
VU-seconds    = Adjusted VUs × Duration (in seconds)
VU Hours      = VU-seconds ÷ 3,600

BrowserStack stores consumption internally in VU-seconds and converts to VU Hours (÷ 3,600) for display on your usage dashboard.

Examples

The following examples show how engines, Adjusted VUs, and VUH scale with your configured VUs:

Browser tests are not adjusted

Browser tests (Playwright, Selenium, WebdriverIO, Nightwatch) run 1 VU per pod, so Adjusted VUs equal your configured VUs. There is no rounding up.

VUH by load profile

How VUH is estimated depends on the load profile you choose:

Multi-region tests

When you split a test across regions, each region runs on at least one engine. BrowserStack allocates engines per region using the following rule:

Engines per region = max(1, floor(region percent × total engines / 100))

Because of this per-region floor, a multi-region test can use more engines, and therefore more VUH than the same test run from a single region.

Consider 1,000 VUs split 60/40 across two regions, running for 10 minutes. The auto engine count is ceil(1,000 / 1,000) = 1, but each region still gets at least one engine:

Adjusted VUs = 2 engines × 1,000 = 2,000
VU Hours     = 2,000 × 600s ÷ 3,600 = 333.33 VUH

Multi-engine tests (JMeter)

For JMeter tests, you can set an explicit engine count instead of letting BrowserStack auto-calculate it. When set, VUH uses that engine count directly. The maximum is 10 engines.

Set the engine count in the Advanced Settings tab in the dashboard, or as engineCount: <number> in your YAML configuration. The following examples show how an explicit engine count changes VUH:

Multi-scenario tests

The multiple scenarios feature models several user journeys in a single test and is available for browser load testing only. Browser tests are not adjusted, so the VUH for a multi-scenario test is the sum of each scenario’s VUs multiplied by the duration.

The following example shows VUH for a two-scenario browser test running for 10 minutes:

Hybrid tests (API + browser)

A hybrid test has an API component (for example, JMeter) and a browser component (for example, Playwright). Each component is charged against its own quota with its own adjustment rules:

API VUH     = Adjusted API VUs × Duration   → charged against your API VUH quota
Browser VUH = Browser VUs × Duration        → charged against your Browser VUH quota (no adjustment)

For a hybrid test with an 80% API and 20% browser split, 500 total VUs, and a 10-minute duration:

API VUs:     400 → 1 engine → 1,000 adjusted × 600s ÷ 3,600 = 166.67 API VUH
Browser VUs: 100 → 100 actual × 600s ÷ 3,600                = 16.67 Browser VUH

Estimated vs. actual VUH

BrowserStack calculates VUH at two points.

Before the test (estimated)

When you start a test, BrowserStack estimates its VUH from Adjusted VUs and checks it against your remaining quota. If the estimate exceeds your quota, the test is blocked before it starts. The estimate gates the run but is not deducted from your quota at this point.

After the test (actual)

VUH is deducted from your quota only after the test reaches a terminal state. Actual VUH is recorded from real pod lifecycle events:

Because actual VUH includes pod startup and shutdown, it can be slightly higher than the execution time alone, typically a few extra seconds per pod. For ramping or spike profiles and for iterations that complete early, actual VUH is often lower than the estimate.

Quota and usage warnings

BrowserStack tracks your VUH against your plan quota and warns you as you approach the limit. The following sections explain how quotas are split and when a test is warned or blocked.

Separate quotas for API and browser

API tests and browser tests draw from separate quotas with different adjustment rules:

80% usage warning

When a test run would push your usage past 80% of a VUH quota, you see a warning. The check is evaluated separately for your API and browser quotas. This is an early heads-up, it does not block the test.

Quota exceeded

If the estimated VUH exceeds your remaining quota, the test is blocked before it starts.

Quick reference

This table summarizes the most common VUH questions:

What’s next

• Load profiles — understand constant, ramping, spike, and iteration profiles.
• FAQs — quotas, test limits, and reset windows.