You've written tests on individual requests. Now imagine running ALL of them at once — 20, 50, 100 requests — with one click. That's the Collection Runner. It executes every request in your collection sequentially, runs all the test scripts, and gives you a pass/fail report at the end.
Click on your collection name in the sidebar
Click the "Run" button (play icon) at the top right of the collection
The Runner opens — you see all requests listed in order
Set Iterations (how many times to run — default is 1)
Set Delay (milliseconds between requests — 0 for fast, 500 for safe)
Uncheck any requests you want to skip (optional)
Click "Run [Collection Name]"
Watch the results — green checkmarks for pass, red X for fail
After the run completes, you get a summary dashboard. It shows total tests, passed, failed, and skipped. Click on any failed test to see the error message — it tells you exactly what assertion failed and what the actual value was.
| Feature | What It Does | When to Use |
|---|---|---|
| Iterations | Runs the entire collection N times | Stress testing, testing with different data each run |
| Delay | Wait N ms between requests | Avoid rate limiting, give server time to process |
| Data File | Feed CSV/JSON data into variables | Data-driven testing — 100 users from a file |
| Keep responses | Save full response for each request | Debugging failed tests — turn off for large runs |
| Save responses | Persist responses after run | Auditing, compliance reporting |
Setting iterations to 5 means the entire collection runs 5 times. If you have 10 requests with 3 tests each, that's 10 x 3 x 5 = 150 test executions. This is useful for catching flaky tests — if a test passes 4 times but fails once, you've got an intermittent bug.
// Use iteration data in your tests
// When running with a CSV data file, access columns as variables
// CSV file (users.csv):
// email,password,expectedStatus
// admin@test.com,Admin123,200
// user@test.com,wrong,401
// ,password,400
// In your test script:
pm.test("Status matches expected", function () {
const expected = parseInt(pm.iterationData.get("expectedStatus"));
pm.response.to.have.status(expected);
});Set delay to 100-500ms when running against shared or staging servers. Running 50 requests with 0 delay can trigger rate limiting and your tests will fail — not because of bugs, but because the server blocked you. Always add a small delay for remote APIs.
Collection Runner runs requests in the order they appear in the sidebar. If your Login request is at position 3 and your Get Profile (which needs a token) is at position 2 — it will fail. Drag and drop requests to set the correct order. Always put authentication requests first.
If you see "Error: connect ECONNREFUSED" in the runner, it means the server is down or unreachable. If you see many tests failing with "getaddrinfo ENOTFOUND" — check your base URL variable. A typo in {{baseUrl}} will fail EVERY request in the collection.
Q: What is the Collection Runner in Postman and how do you use it?
A: The Collection Runner lets you execute all requests in a Postman collection sequentially with one click. I configure iterations (how many times to run), delay between requests, and optionally attach a CSV or JSON data file for data-driven testing. After the run, it shows a pass/fail summary for all test assertions. I use it for regression testing — run the entire collection after every deployment to ensure nothing broke. For more advanced scenarios, I export the collection and run it via Newman in CI/CD pipelines.
Key Point: Collection Runner executes all requests in order, runs every test script, and gives you a pass/fail report. Use iterations and data files for data-driven testing.