November 2, 2026

Your requests and functional tests already live in a Postman collection. Load testing usually means rebuilding them in a second tool, with a second syntax.

You don’t have to. Your first performance test in Postman reuses the collection you already have. By the end of this post, it will run on Postman Cloud runners with a pass/fail threshold your CI job can gate on. You’ll also hand the same test to a coding agent with one prompt.

What does a first performance test need?

Pick a real workflow. Set a virtual user count and a duration. Add pass/fail thresholds for p95 latency and error rate. Then run it from where the load actually needs to come from. Use cloud runners if you need volume, or run locally if you’re just doing a quick check.

Say you have a checkout collection that already passes functional tests. Your first performance test in Postman reuses that same collection. Each virtual user runs the selected requests in order, in a repeating loop, for the duration you set.

How do you run your first performance test in Postman?

Pick a collection that already passes its functional tests.
Open Postman, select the collection, and click Run.
Under Run type, choose Performance.
Set the virtual user count, the duration, and a load profile.
Add a pass/fail threshold, such as p95 latency.
Pick Cloud as the runner and click Run on Cloud. Pick Local instead for a quick check on your own machine.
Watch the real-time timeline as virtual users ramp up. When the run ends, open it in Postman to see where latency rose and which requests slowed first.

How do you run one from the Postman CLI?

The Postman CLI is where performance testing stops being a one-off and starts being something you can wire into CI.

Then run a performance test against a collection by ID:

Add a pass/fail threshold so the run exits non-zero when latency or errors cross a line:

If p95 latency stays under the threshold, the command exits 0. If it doesn’t, the command exits non-zero and your CI job fails. See the Postman CLI performance testing docs for every option.

Where should the load come from?

The load comes from the machine that starts the run, or from Postman Cloud runners when you add --runner postman-cloud to the same command.

When should you run locally?

Run locally while you’re building the test. A local run generates load from the machine that starts it, your laptop or a CI runner, and local performance testing is unlimited on every plan. Use it to check request order, test scripts and thresholds at low load. Watch your machine’s health, since a busy machine skews results. Move to Postman Cloud runners when you need more load than one machine can produce.

When should you run on Postman Cloud?

Adding --runner postman-cloud to the same command spreads load across multiple machines. You get more concurrent requests than a single laptop or CI runner can produce, and there are no load generator boxes to maintain. Cloud runs keep going if you close your computer, and they persist metrics, assertions, errors, and system metrics in Postman for later analysis and comparison.

The command returns the --pass-if result as its exit code, so set the CI job timeout to at least the test duration. A 30 minute run with a 10 minute job timeout is just a flaky test.

If the API you’re hitting sits behind an IP allowlist, use --runner postman-cloud-static-ip. That gives you fixed IPs in your account’s region (US, or EU for EU Data Residency) that you can allowlist on the target. For a full walkthrough, see how to load test an API behind a firewall.

A few more things worth knowing:

Results are recorded in Postman for the workspace, so anyone with access can open the run and see what happened.
On cloud runs, --data-file becomes a dataset uploaded to Postman, and secrets move to a Shared Vault secret rather than a local env var.
Setup and teardown collections require --runner postman-cloud.
Cloud runs and static IPs are available on paid plans.

Can a coding agent do this for me?

Yes. The Postman plugin brings Postman skills into Claude Code, Codex, Cursor, OpenCode, Pi, and other coding agents, and runs tasks through the Postman CLI.

Install it one of these ways:

That requires Node.js 22 or later.

For Claude Code:

For Cursor:

The performance-testing skill load tests a collection with virtual users, a load profile, and pass/fail thresholds, locally or on Postman Cloud runners.

A prompt I actually use:

The agent turns that into a postman performance run command with --runner postman-cloud and a --pass-if threshold, runs it through the Postman CLI, and reports the result. The run is recorded in Postman for the workspace.

How do you tell it actually worked?

The exit code is the first signal. Zero means your thresholds held. Non-zero means they didn’t.

Open the recorded run in Postman for the timeline. Look at where p95 bent upward, whether errors clustered at a specific virtual user count, and which requests slowed down first.

What are the honest limits?

A few things to be upfront about. Cloud runs work from the Postman web app and the desktop app. Local runs need the desktop app or the Postman CLI, since the load comes from your own machine. Each virtual user runs the selected requests in order, in a repeating loop, so if you need wildly branching user behavior you’ll want to split that into separate collections. Cloud runs and static IPs are available on paid plans.

FAQ

Can I use my functional test collections for load testing?

Your functional test collections can run as performance tests without a rewrite. Each virtual user runs the selected requests in order, in a repeating loop, and pass/fail thresholds decide the result. Start locally, then use Postman Cloud runners when you need more load than one machine can produce.

How do I wire this into CI?

Add a postman performance run step with --runner postman-cloud, a --vu-count, a --duration, and a --pass-if expression. Set the job timeout to at least the test duration. The exit code gates the pipeline, and the run is recorded in Postman for the workspace.

Do I need a paid plan?

Local performance testing is unlimited on every plan, including Free. Cloud runs and static IPs are available on paid plans, and cloud runs are billed at $0.04 per virtual user hour. A 30-minute run with 100 virtual users uses 50 virtual user hours, or $2. See Postman pricing for current plan details.

Can I reuse my environments and data files in a cloud run?

The same collection you use for functional runs works for performance runs. On cloud runs, --data-file becomes a dataset uploaded to Postman, and any secrets should move from environment variables to a Shared Vault secret so they’re not sitting in a local file.

How many virtual users should I start with?

Start with a small virtual user count and a short duration, and calibrate your thresholds against a healthy run. Once you know what normal looks like, increase the load. When you need more than your machine can produce, add --runner postman-cloud to the same command.

Try it

The full configuration reference is in the performance test configuration docs, and the agent install options are in the Postman plugin overview.

Try Postman now.

Resources

Performance test configuration: full reference for virtual users, load profiles, --pass-if thresholds, and cloud runner flags.
Postman CLI performance testing: every option for postman performance run, including runners and thresholds.
Postman plugin overview: install options for Claude Code, Codex, Cursor, OpenCode, and Pi, plus the skills the plugin exposes.
Postman CLI overview: install, authenticate, and run collections from any CI system.
How to load test an API behind a firewall: using static IPs so your allowlisted API accepts cloud load.
Can Postman do load testing? Yes, here’s how it works: background on why reusing functional collections for load tests cuts the second suite.