Running Collections with Collection Runner

You've built a collection: requests, tests, environments, chained variables. Up to now you've sent each request manually, one at a time. The Collection Runner runs the whole thing — every request in order, every test evaluated, with one button click. It's how you turn an ad-hoc set of saved calls into a test suite. This lesson walks through opening the Runner, configuring its options, reading its results, and using flow-control commands to skip or stop runs mid-flight.

What the Collection Runner does

The Runner takes a collection (or a folder inside one) and executes its requests in the order they appear in the sidebar. For each request it:

Resolves variables against the active environment.
Runs the pre-request script.
Sends the request.
Captures the response.
Runs the Tests script.
Records pass/fail per pm.test() block.

When the run finishes you get a summary — how many requests went out, how many tests passed, how long it all took, and per-iteration drilldown for any failures. It's effectively the GUI version of what Newman does in the terminal (next lesson).

Opening the Runner

Three equivalent paths:

Click the collection in the sidebar → Run button (top-right of the collection panel).
Right-click the collection or folder → Run collection / Run folder.
Bottom-bar → Runner — opens the Runner without preselecting anything.

Whichever route, the Runner opens in a dedicated tab with the collection's requests pre-listed on the left.

Runner options, top to bottom

The configuration panel offers everything you need to shape a run:

Select requests. Tick or untick which requests to include. By default everything is on. Useful when you want to skip slow setup requests or run only a folder.
Run order (drag to reorder) — the displayed order is what gets executed. Postman warns if you re-order in a way that breaks dependencies.
Iterations. How many times to run the whole selection. Defaults to 1; with a data file (Chapter 4 Lesson 2) it auto-fills to the row count.
Delay. Milliseconds between requests. 0 = as fast as possible. 100–500ms is polite for rate-limited APIs. 1000+ when you need to watch a run unfold visually.
Data file. A CSV or JSON file for data-driven runs (covered in detail last chapter). The Runner iterates one request set per row.
Environment — top-right dropdown. Make sure the right environment is active ({{baseUrl}} resolves through it).
Save responses, persist variables, run collection in order — three checkboxes. Defaults are usually right; the only one you'll change is "Save responses" if you want each iteration's response captured for later review.

Set the options, click Run at the bottom. Postman fires through the requests one at a time.

The execution flow, step by step

Step 1 of 5

Configure

Pick environment, data file (if any), iteration count, and delay. Tick the requests to include and confirm their order.

The sequence is the same whether you have 5 requests or 500.

Reading the results

The result panel shows, per request:

Request name and method.
Status code (with the same colour pill as the response panel).
A green tick / red cross for the test outcome.
Response time in milliseconds.

At the top, the summary strip shows: iterations completed, requests sent, test assertions (passed / failed / total), and average response time. The visual cue is colour: a green strip means everything passed; an amber/red strip means at least one assertion broke.

Click a failed request to expand it. You'll see:

The actual request that went out (URL, headers, body — exactly what hit the wire).
The response (status, headers, body).
Each pm.test() result with its assertion message — the same one the Test Results tab shows on a single send.

The Runner also keeps run history. Switch to the Runs tab in the collection sidebar to see past runs with timestamps. Useful for "did the suite get slower this week?" or "when did this test start failing?"

Order matters

The Runner executes requests in the order they appear inside their folder (and folders in the order they appear in the collection). For chained workflows (Chapter 4 Lesson 1), this is critical:

JSONPlaceholder API Tests/
└── CRUD Chain/
    ├── 1. POST Create Post     ← runs first
    ├── 2. GET Verify Created   ← uses createdPostId from step 1
    ├── 3. PATCH Update Title   ← also uses createdPostId
    ├── 4. DELETE Post
    └── 5. GET Verify Deleted

Drag a request out of order and you break the chain. Newcomers sometimes alphabetically sort their folders and silently break their own tests; numbered prefixes (1., 2., 3.) keep the intent obvious.

Controlling flow with `postman.setNextRequest`

By default the Runner moves linearly. You can override that from any pre-request or test script:

// Skip ahead to a specific request by name
postman.setNextRequest("GET User Profile");
 
// Stop the run entirely
postman.setNextRequest(null);

Two real use cases:

Stop on critical failure. If POST Login fails, no point running the 30 authenticated requests after it. In the login's Tests script:

if (pm.response.code !== 200) {
    console.error("Login failed — aborting collection run.");
    postman.setNextRequest(null);
}

Conditional flow. Skip a setup step if the data is already there:

if (pm.collectionVariables.get("authToken")) {
    postman.setNextRequest("GET Users"); // Skip login, go straight to authenticated calls
}

Two important notes: postman.setNextRequest("Name") matches by request name within the current collection (not folder-aware in older versions), and the override only applies to the next request — subsequent requests resume linear order.

Running just a folder

For long collections, running a single folder is the day-to-day move. Right-click the folder → Run folder. The Runner opens with only that folder's requests pre-selected. Same options, faster iteration.

This is also how you organise a collection: top-level "Smoke" folder for quick health checks, "CRUD Chain" folder for the lifecycle test, "Negative Cases" for the failure-mode exercises. Each is a sub-suite you can run independently.

What the Runner doesn't do

A few things to know before you reach for it:

Parallel requests. The Runner is sequential. To hit endpoints in parallel for load testing, use a real performance tool (k6, Locust, JMeter — referenced in the masterclass Response Time and Performance lesson).
Branch on response shape. You can setNextRequest based on response data, but for genuinely complex workflows (loops over arrays, conditional branching trees), Postman Flows (Chapter 6) is the cleaner tool.
CI-friendly output. The GUI Runner shows results in a panel; CI needs a machine-readable file. That's Newman's job (next lesson).

For 95% of normal API test workflows, the Runner is exactly what you want.

⚠️ Common mistakes

Forgetting to switch the environment before running. Running against production by accident is the textbook horror story. Glance at the environment dropdown (top-right) before clicking Run; double-check before any destructive collection.
Re-ordering requests and breaking chains. Drag-reordering inside a folder is silent — Postman doesn't warn that GET Verify Created now runs before POST Create Post. Use numbered prefixes (1., 2.) to keep the order visible at a glance.
Treating per-request response times as load-test data. The Runner sends one request at a time. A 100ms response time when the server has zero other load is not a performance signal — your real users hit it concurrently.

🎯 Practice task

Run a collection end-to-end. 25-30 minutes.

Open your JSONPlaceholder API Tests collection. Make sure the JSONPlaceholder environment is active (top-right dropdown).
Right-click the collection → Run collection. The Runner opens with every request preselected.
Click Run. Watch each request fire in turn. Note the live counter in the summary strip — passed/failed should tick up as each request's tests evaluate.
After the run finishes, read the summary: total requests, total tests, average response time. Click any request in the result list to drill into its request/response and Test Results.
Run just a folder: right-click your CRUD Chain folder (built in Chapter 4) → Run folder. The Runner now shows only the chain's five requests. Click Run. All five should pass with createdPostId flowing through correctly.
Force a chain break. Edit 1. POST Create Post's URL to /postsxxx (an invalid path). Re-run the folder. The first request fails; subsequent ones cascade-fail because createdPostId was never set. Open the failed request to see the assertion message. Revert the URL.
Add a flow-control rule. In 1. POST Create Post's Tests tab, add at the bottom:
```
if (pm.response.code !== 201) {
    postman.setNextRequest(null);
}
```
Re-break the URL and re-run the folder. Now only the first request runs — the runner stops cleanly instead of cascading failures. Revert.
Stretch: add a Delay of 200ms in the Runner config and re-run. Notice the visible pause between requests. Useful when watching a run unfold to spot anomalies, or when the target API has a per-second rate limit.

You can now run an entire suite from the Runner in seconds. The next lesson takes the same collection and runs it from the command line — no GUI, no Postman app, just JSON files and a terminal. That's what makes Postman tests CI-friendly.