Collection runner

The runner sends a list of requests one after another and checks each response. Use it to run a whole test suite with one click, to repeat a request several times, or to keep watching an endpoint on a timer.

Start a run

1. In the sidebar, open the menu of a collection and select Run collection.

   To run part of a collection, open a folder's menu and select Run folder. It runs the folder and its subfolders.

2. The runner opens with the title Run • and the collection's name. The top line shows how many requests are in the run.

3. Select Run.

4. Watch the results appear, one row per request. Select a row to expand it and see each test.

To run a single request, open its More menu (the three dots next to Send) and select Run repeatedly / on interval….

Requests run in the order they have in the collection. The runner sends HTTP requests; WebSocket, Socket.IO, MQTT, SSE and gRPC requests in the collection are left out.

Settings

Setting	What it does	Default	Range
Iterations	How many times to send the whole list. Each pass sends every request in order.	1	1 to 100
Delay between (ms)	Pause after each request before the next one, in milliseconds.	0	0 to 60000
Recurring	Keep repeating the list on a timer until you select Stop.	Off
Every (s)	With Recurring on: seconds to wait after one pass ends before the next starts.	30	5 to 3600
Data	Opens the data panel, to run once per row of a CSV or JSON file. See Data-driven runs.	No data
Keep variable values	Whether variable changes made during the run are saved. See below.	On

A value outside its range is moved to the nearest allowed value when you select Run.

TIP

A small Delay between (ms), such as 200, is kind to shared test servers and avoids tripping rate limits.

Recurring mode

Turn on Recurring to watch an endpoint over time, for example every 60 seconds through an afternoon. Iterations is ignored; the run continues until you select Stop. Between passes the runner shows pass 3 done — next pass shortly….

For checks that should run on a schedule without the app open, use the command-line runner from a scheduler or CI. See Monitoring.

Stop a run

Select Stop. The request in flight is cancelled and the run ends. Results so far stay on screen.

When a request passes or fails

Result	When
Passed	Every test passed. With no tests at all, the status was below 400.
Failed	A test failed, a script threw an error, the status was 4xx or 5xx with no tests, or no response came back.
Skipped	A pre-request script called pm.execution.skipRequest(). Counts as passed.

"Tests" means both the no-code checks in the request's Tests tab and pm.test calls in its scripts.

Note the middle case: once a request has at least one test, the status code alone no longer decides. A 404 passes if all its tests pass, which is what you want when you are testing that a missing item returns 404.

Read the results

The summary at the top covers the whole run:

Tile	Meaning
Passed	Requests that passed
Failed	Requests that failed
Avg	Average response time: total time divided by the number of requests
Min	The fastest response
Max	The slowest response. Spikes here point to timeouts or a struggling server.

Each row shows the request, then a line like this:

pass 2 • 200 • 85 ms • 3/3 tests

That is the pass number, the status code, the response time and how many tests passed. A request that got no response shows error in place of the status.

Expand a row to see:

• one line per no-code test, with a tick or cross and its message;
• one line per pm.test, with its error when it failed;
• Script error: and the message, when a script threw;
• No tests on this request — judged by status code. when it has none.

The runner shows status, timing and test results, not response bodies. To inspect a body, open the Console or send the request from the editor.

The list keeps the newest 200 results. On longer runs it says Showing 200 of 1250 results; the counts and times still cover every request.

How scripts, tests and captures behave

Each request in a run goes through the same steps as a single send:

1. Collection, folder and request pre-request scripts.
2. The request is sent, with inherited auth applied.
3. Collection, folder and request post-response scripts.
4. The no-code tests.
5. The captures.

What is different in a run:

• Variables carry over. A value that a capture or script sets in one request is available to every request after it, in this pass and later ones.
• Scripts can change the order. pm.execution.setNextRequest("Request name") jumps to that request next, and pm.execution.setNextRequest(null) ends the current pass. An unknown name also ends the pass. A pass is stopped after 10,000 jumps.
• Scripts know the iteration. pm.info.iteration counts from 0, and pm.info.iterationCount is the planned number of passes (0 in recurring mode).
• Data rows. With a data file, each pass gets one row as variables and as pm.iterationData.
• Cookies. The run uses the app's cookie jar, so a login cookie set by one request is sent with the next.

Script output from a run goes to the Console.

Variables during a run

Keep variable values decides what happens to variable changes:

Switch	During the run	After the run
On	Scripts and captures write to the environment, collection and globals	The new values stay, as if you had sent the requests by hand
Off	The run works on copies	Every change is thrown away

Leave it on when you run a login request and want to use its token afterwards. Turn it off when the run should leave no trace, for example a test suite that creates temporary ids.

Example: a create, read, delete chain

A collection with three requests:

Order	Request	Tests	Captures
1	POST {{baseUrl}}/todos	Status equals 201	todoId = body.id
2	GET {{baseUrl}}/todos/{{todoId}}	Status equals 200, JSON field equals title
3	DELETE {{baseUrl}}/todos/{{todoId}}	Status equals 2xx

Select Run collection, then Run. Three rows appear, each marked passed. Set Iterations to 5 and run again: 15 results, with a new todoId captured in every pass.

You can try this with the Todo API sample project.

Next steps

• Data-driven runs: run the same requests with many sets of values.
• Command-line runner: run collections from a terminal or CI.
• Load testing: many simulated users at once.
• Test plan: decide what a run should cover.