NBomber load testing: a review of the .NET framework

NBomber is a load testing framework for .NET: you write each test as a C# or F# scenario, add it to an ordinary project and run it like any other program. NBomber load testing suits teams that already build in .NET and want their load tests in the same language, the same repository and the same test runner. NBomber is free for personal and academic use only; a company needs a paid licence, and that one fact decides more evaluations than any feature.

We have not run NBomber for this review. The facts come from NBomber’s documentation, pricing page, GitHub repository and NuGet package, checked on 21 October 2026, and the judgements are ours.

Who makes NBomber, and is it free?

NBomber LLC develops it, with the source on GitHub. It is free for personal, hobby and academic use, and the licence page states plainly that NBomber is not free for organisational use.

The licence page counts benchmarks, tutorials and review content as personal use. Inside a company you need a Business or Enterprise licence, issued per organisation rather than per developer seat, and with no limit on instances or parallel runs. The pricing page lists Business at $1,500 a year and Enterprise at $2,500 a year, both with a 30-day money-back guarantee. The licence key goes into the runner with .WithLicense(...) or a --license argument, and NBomber needs internet access to validate it, with offline validation available on request by email (checked on 21 October 2026).

The latest release is v6.7.1, published on 16 October 2026, after 6.7.0 four days earlier (checked on 21 October 2026).

How does an NBomber scenario work?

A scenario is a name plus an async function that NBomber times on every call. You attach load simulations and thresholds to it, register it with NBomberRunner and run the program.

This test skips the warm-up, ramps the arrival rate to 50 new scenario copies a second over two minutes, holds it for ten minutes, and exits with code 1 if 1% or more of requests failed. It uses the NBomber.Http plugin for the request:

var http = Http.CreateDefaultClient();

var scenario = Scenario.Create("browse", async context =>
{
    var request = Http.CreateRequest("GET",
        "https://staging.example.com/products");
    return await Http.Send(http, request);
})
.WithoutWarmUp()
.WithLoadSimulations(
    Simulation.RampingInject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(2)),
    Simulation.Inject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(10)))
.WithThresholds(
    Threshold.Create(s => s.Fail.Request.Percent < 1));

var result = NBomberRunner
    .RegisterScenarios(scenario).Run();
return result.Thresholds.Any(t => t.IsFailed) ? 1 : 0;

The HTTP client page recommends Http.CreateDefaultClient() over a plain new HttpClient() and says the plugin tracks status codes and data transfer (checked on 21 October 2026). A threshold on its own only records the failure in the report, so the last line turns it into an exit code a pipeline can read. Without .WithoutWarmUp(), NBomber first runs a 30-second warm-up with the scenario’s own simulations, per the scenario page (checked on 21 October 2026). Because the scenario is plain C#, anything a .NET library can call can be load tested the same way.

What load models does NBomber offer?

Both kinds. The inject simulations start new copies at a set rate whatever earlier copies are doing, which is an open model; the constant simulations keep a fixed number of copies running, which is a closed one.

The load simulation page lists them (checked on 21 October 2026):

• Open: Inject, RampingInject, InjectRandom and IterationsForInject.
• Closed: KeepConstant, RampingConstant and IterationsForConstant.
• Timing: Pause, which delays a scenario’s start or pauses it for a set time.

Our article on the open vs closed workload model explains which one matches your traffic. A public website usually behaves like the open model; a fixed pool of internal clients, like the closed one.

How do thresholds and pass/fail checks work?

Runtime thresholds check the running statistics, every 5 seconds by default, and appear in the HTML report. Asserts, written in xUnit or NUnit, check the final statistics after the run, and a failed assert ends the run with a failed status.

The thresholds page shows checks on error percentage, status codes, latency percentiles (p50, p75, p95, p99 and max), requests per second and bytes transferred. A threshold does not stop the test by default; abortWhenErrorCount makes it stop after a set number of failed checks (checked on 21 October 2026). The page does not state an exit code, which is why the sample above returns one from the result. Our guide to load test pass/fail criteria covers which limits to set.

Which protocols can NBomber test?

Any protocol a .NET library can speak, because NBomber only times the code you give it. Ready-made plugins cover HTTP, WebSockets, MQTT and AMQP, plus a WebBrowser option.

The overview page describes the framework as having no dependency on a protocol, and the pricing page lists those plugins in every plan, including the free one. That also covers databases and message queues you call through their own .NET clients (checked on 21 October 2026). The trade-off is that outside the plugins you write and maintain the client code yourself.

How do you scale out an NBomber test?

With NBomber Cluster: one Coordinator orchestrates the run and Agents execute the scenarios, all talking through a NATS message broker. Cluster is part of the Enterprise licence.

The cluster overview explains the roles, and the licence page says developers can try it locally with a Local Dev Cluster before buying; the Local Dev Cluster page limits it to 1 Coordinator and 2 Agents and stops each run after one minute (checked on 21 October 2026). NBomber Studio’s Kubernetes integration, also Enterprise-only, provisions NATS and the Agent pods for you. Without Cluster, one NBomber process runs on one machine; the system requirements page suggests 4 to 8 CPU cores for high load.

LoadFocus, which publishes this site, does not run NBomber tests. It runs JMeter test plans and k6 scripts from 25 cloud regions.

What does NBomber do well, and where are its limits?

It is strong for .NET teams: tests are C# or F# code, any .NET client becomes a load test, and both load models are built in. Its limits are the company licence, a single-language ecosystem and paid distributed runs.

• Tests live next to the application code, with the same IDE, packages and reviews.
• Thresholds are built in, and asserts run inside the xUnit or NUnit tests you already have.
• Commercial use needs a licence, even for a single developer.
• Distributed runs need Enterprise and a NATS broker.
• Non-.NET testers cannot pick it up without learning C# or F#.

When should you choose k6, Gatling or JMeter instead?

Choose another tool when your team does not write .NET, or when the licence cost does not fit.

Choose k6 instead when you want JavaScript scripts and an open source tool with no licence fee for company use: its repository is AGPL-3.0 (checked on 21 October 2026). LoadFocus runs k6 scripts from 25 cloud regions, though it runs arrival-rate scenarios with a fixed number of users. Choose Gatling instead for a code-first JVM tool; our Gatling review covers it. Choose JMeter instead when testers prefer a GUI or you need JDBC, JMS or LDAP samplers out of the box. The open source load testing tools overview sets those side by side.

FAQ

Is NBomber free for commercial use? No. NBomber is free for personal and academic use only. A company needs a Business licence at $1,500 a year or an Enterprise licence at $2,500 a year.

Which .NET versions does NBomber support? It targets .NET Standard 2.1, so it runs on .NET Core 3.0 and every later .NET version. The documentation recommends .NET 10.

Can LoadFocus run NBomber tests? No. LoadFocus runs JMeter test plans and k6 scripts. To run NBomber on more than one machine, use NBomber Cluster, which needs an Enterprise licence.

Related reading

• Gatling load testing: a review of the JVM tool
• Open source load testing tools: six options reviewed
• Open vs closed workload model: which one should you use?
• Load test pass/fail criteria: how to set them
• Tsung load testing: a review of the Erlang tool

The technical claims in this article have not been independently reviewed.