Translate your test mix & schedule into recommended A-units. Hover the blue icon for help on each control.
View Model Specs & Concurrency Details (in Sidebar)
Quick Sizing (Optional)
Use this for a fast estimate. This will populate the granular table below.
Granular Test CPU Budgets (%)
Workload Definition (Granular Test Mix)
Type
Avg Dur (s)
Sched/Window
Freq (min)
Fail %
Debug
Verify
Action
⭐ Pro-Tip: Optimize for Concurrency
Detailed Requirement Breakdown
Baseline Model
Total Workload t/s (A1 Eq)
Licenses (CPU)
Licenses (Concurrency)
Final (A-units)
Bottleneck
Understanding Your Results: CPU vs. Concurrency (Slippage)
Your Final License count is the maximum of two separate requirements: 1) CPU Capacity and 2) Concurrency Slots. The "Bottleneck" column shows which requirement was higher.
1) CPU Capacity (Throughput)
This is the raw processing power required to run all your tests, normalized to an A1 unit (t/s or 'tests per second'). It answers: "Do I have enough *total engine power*?"
This is the number of parallel "slots" needed to run your tests within their frequency window. If this number is the bottleneck, you will experience **test slippage**, where tests are delayed until a slot is free.
Example: You have **20 Browser tests** at a 5-minute frequency, and you choose a **2 x A4 model** means 2 instances of A4 each, hence total ndoe capacity is 8 (which provides 2 x 4 concurrent Browser slots, and say each test-depending on single step for this run is taking around 2-3 mins in total including processing, which means 8 tests start in first batch, 8 in second batch). In this specific scenario we were able to run 16 browser tests in this 5 min window instead of mentioned 20, so the last 4 in this specific case slip from the window to next slot (This example is just for representation).
At 10:00, the first 8 tests run.
At ~10:03, the next 8 tests will run.
At ~10:06, the final 4 tests + may be first 4 again will run and so on
The first batch of tests can't run again at 10:05 because the node is still busy. This is **slippage**. The tool calculates the total slots needed and compares it to the model's capacity to determine the license requirement.
This tool calculates capacity based on your inputs, but real-world performance can be affected by:
Target Performance: Slow web pages or endpoints will increase test 'Avg. Duration', which directly increases concurrency pressure and can cause slippage.
Network/Proxy Health: Network latency or slow proxies add to the test duration.
Test Options: Enabling 'Debug' or 'Verify' adds overhead and increases both CPU and duration.
Fleet Analysis
Upload nodes & instances or add nodes manually. Use NodeProcTime for better derived utilization.
Current Fleet Snapshot (editable)
Node Name
Model
Active Inst
Licenses
Overall Util%
Tests/Hour
Browser T/H
Emulated T/H
HTTP T/H
Errors/hr
Action
Instances
Auto
N/A
📊 Fleet Health Report & Recommendations
Node
Model
Inst
Licenses
License Util
Test Volume
Error Rate
Status
Recommendation
⚠️ Instance Resource Warnings
Health Check Logic & Recommendations
Derived utilization uses tests/hour and Node Processing Time when present. Thresholds: warn@80% and crit@90%.
Error Thresholds: OK < 50/hr, Warn 50-100/hr, Critical > 100/hr.
Memory and instance CPU are used for warning signals only.
Node Diagnostic — Single Node Deep-Dive
Instance ProcTime removed. Use Node Processing Time (s) below which multiplies per-test CPU demand for diagnostics.