One fast Send doesn’t prove an API is healthy under traffic. Use a short Functional runner pass, then learn why avg vs p95 change the decision — before you open the Performance tab.
Why averages can mislead
This step uses the Collection Runner in Functional mode — not the Performance tab yet. You’re collecting a handful of timings so variability is visible, then learning how Postman summarizes many timings with avg vs percentiles.
1. Run a short Functional collection run
- Confirm the Performance environment is selected in the top-right environment picker (the one you created in Step 3 — not the Performance runner).
- Select Coffee API Load Test → open the Collection Runner (⋯ → Run or Run on the tab bar).
- Stay on Functional (leave Performance alone for now).
- Set Iterations to
10, keep the Performance environment selected, and start the run. - When it finishes, skim the results: each iteration has its own response time. They won’t be identical — that’s normal. Write down the fastest and slowest times you see for Get Hot Coffee.
2. What the summary metrics mean
When Postman aggregates many requests under load, it reports more than a single average. From the performance metrics guide:
| Metric | Plain-language meaning |
|---|---|
| Avg. response time | All response times added up, divided by the count |
| P90 / P95 / P99 | The time at which 90% / 95% / 99% of requests were at or faster than this value — the rest were slower |
| Error % | Requests that failed to complete normally (timeouts, connection/TLS issues, uncaught script errors) |
| Failure % | Requests that completed but failed at least one pm.test() assertion |
P95 is the one teams watch most often: “95% of users were at or under this latency; 5% were worse.”
3. Worked example — why the average can look “fine”
Imagine 20 requests with these response times (ms):
180, 190, 200, 200, 210, 210, 220, 220, 230, 230, 240, 240, 250, 260, 280, 300, 900, 2100, 3200, 4800
| Summary | Value | What a reader might think |
|---|---|---|
| Average | ~720 ms | “Under a second — acceptable?” |
| Median (p50) | ~235 ms | “Most requests are snappy” |
| P95 | ~3200 ms | “1 in 20 requests takes ~3+ seconds” |
| P99 | ~4800 ms | “The worst few are almost 5 seconds” |
The average is pulled up by a few slow requests, but it still understates how bad the tail feels. If you only watched average, you might ship; if you watched p95, you’d investigate.
Here’s a compact “report card” in the same shape Postman shows after a performance run:
| Metric | Value |
|---|---|
| Average response time | 720 ms |
| Median | 235 ms |
| P95 | 3.2 s |
| P99 | 4.8 s |
| Error rate | 0% |
Ask: Would you call this API healthy based on the average alone? What decision changes when you look at p95?
Expected outcome: You’ve seen real timing variance across 10 Functional iterations, and you can explain in one sentence why p95 (or p99) catches problems that average misses.