October 27, 2026

Your checkout Collection signs in, adds an item, applies a coupon and asserts on the response. It runs green on every pull request. Then someone asks for a load test, and the plan turns into a second suite in a second tool. This is what most of our customers faced, and exactly the reason why we built Performance testing in Postman.

A single collection can double both as a functional test and Performance test. Just setup the performance test configuration like virtual users, load profile and duration. Your existing assertions in your collection runs under load. You can further gate your build on p95 latency or error rate.

Postman’s Performance tests can run from your laptop while you iterate, or deployed to the cloud for up to 1 million VUs and can be integrated to your CI as a gate.

What does Postman load testing actually look like in practice?

Say you have a checkout Collection. It signs in, adds an item, applies a coupon, hits /checkout, and verifies the response with a few pm.test() checks. It runs green on every PR. Your release rule is “p95 under 500 ms at 200 VUs.”

With Postman load testing, that same Collection is the load test. You point the performance runner at it, tell it how many virtual users you want and for how long, and each VU loops through the Collection in parallel. The scripts run. The pm.test() assertions run. The sign-in step still extracts the token the way it always has. You don’t rebuild anything in another DSL and you don’t maintain a second copy of the auth flow.

You can run it from the Postman app, the Postman CLI, or on Postman Cloud. The Collection is the same artifact in all three.

What about k6, JMeter, Gatling, Locust, or ReadyAPI?

All of these are solid. The honest comparison is what you’d be maintaining in parallel.

The question isn’t which tool is best in isolation. It’s whether a second suite is worth building when the first one already describes your API.

How do I actually run one?

Start locally. Open a terminal and run:

--peak-vu sets the virtual user count. --duration is in whole minutes. --load-profile takes fixed, ramp-up, spike, or peak. --pass-if evaluates after the run against one of avg, p90, p95, p99, error_rate, or rps.

The exit code matters for CI. When --pass-if fails, the command exits non-zero. Without --pass-if, the command always exits 0. So if you want CI to actually fail the build, pass the assertion.

Here’s the same step in a GitHub Actions workflow:

If p95 drifts above 500 ms, the step exits non-zero and the PR goes red. Same Collection, same assertions, new gate.

Where should the load come from?

Local runs are great while you’re iterating. The capacity depends on your machine, which is fine for a smoke-level check but may not reach production-level traffic.

For higher load, add --runner postman-cloud to the same command. The load is distributed across Postman’s machines, so you get more throughput than one laptop and nothing to provision. The command still returns the --pass-if result as its exit code, so your CI job can gate on it the same way. One thing to watch: set your CI job timeout to at least the test duration, otherwise CI may cancel the job before the result comes back.

If your API lives behind an allowlist, use --runner postman-cloud-static-ip. You get fixed IPs in your account’s region (US, or EU for EU Data Residency) that you can add to the allowlist. The static IPs documentation has the current list for your region.

A few data notes. Cloud run results are recorded in Postman for the Workspace, so your team can open the run after the fact and compare. Data files move from --data-file to a dataset, which works wherever the command runs. Secrets move to a Shared Vault secret. Local Vault secrets are not available in cloud runs.

How do I tell it actually worked?

Open the run in Postman and you get the metrics view: p90, p95, p99, average, error %, and failure %. Error % counts requests that errored. Failure % counts pm.test() assertions that failed under load. Those two numbers tell different stories and both matter.

The Tests vs VU heatmap shows the VU count where assertions start failing. You can also compare two runs side by side, which is handy when you’re trying to prove a fix actually moved p95.

What are the limits of Postman load testing?

A few things to know going in:

The model is VU-only. You pick the number of virtual users, not a target requests-per-second. If you need to think in RPS, the RPS calculator at postman.com/tools is a decent starting point for converting between the two.
One region per account. Cloud runs come from the region tied to your account.
The test config isn’t a file in Git. The CLI command is the config-as-code, and the flags you commit to your workflow file are the source of truth.
--pass-if gates on latency, errors, and throughput. It doesn’t gate on pm.test() assertion failures. If assertions failing under load is your real signal, watch failure % in the results view.
HTTP requests only. No load generation for gRPC, GraphQL subscriptions, or WebSocket.
No native export to Grafana, Datadog, or OpenTelemetry. Results live in the Workspace.

Frequently asked questions

Can Postman fail a CI build on load test results?

Pass --pass-if with a metric and threshold, like "less_than(p95, 500)" or "less_than(p99, 800)". When the condition fails after the run, the CLI exits non-zero and the CI step fails. Without --pass-if, the command always exits 0, so the build stays green. The same gate works with --runner postman-cloud; set the CI job timeout to at least the test duration.

Is Postman load testing free?

Local runs are available on all plans. Cloud runs and static IPs are available on paid plans. Cloud runs require a minimum of 10 virtual users, and local capacity depends on your machine. If you want to try a quick load test without signing up, there’s a free no-signup API load test (100 VUs, 60 s, GET only) and an RPS calculator at .

Should I convert my Postman Collection to k6?

k6 is a strong tool, especially if your team already writes JavaScript test code and wants arrival-rate executors. The question is whether maintaining a second suite is worth it when your Postman Collection already defines the requests, auth, and assertions. If you need k6’s model specifically, keep it. Otherwise, running the Collection you have is usually less work.

How do VUs translate to requests per second?

VUs loop through the Collection in parallel, so RPS depends on how long one full loop takes. 50 VUs on a four-request Collection that takes 2 seconds per loop send about 100 requests per second. To hit a specific RPS, work backwards from your average loop time, or use the RPS calculator at postman.com/tools. For the full sizing method, see How many virtual users do you need for a load test?

How do datasets and secrets work on cloud runs?

Datasets work wherever the command runs, local or cloud, so a dataset you attach to the run is available to every VU. Secrets are different. Local Vault secrets are not available in cloud runs; you need to store them as Shared Vault secrets so the cloud runners can read them. Move credentials over before switching the runner.