Postman Performance Testing

A correct API can still fail under pressure. Performance testing measures how an API behaves when many users arrive at once. Postman includes a performance mode in the Collection Runner that simulates virtual users and reports response times, error rates, and throughput.

Why Speed Under Load Matters

A small café serves five customers calmly. A morning rush of fifty customers creates long queues, mistakes, and angry faces. Servers behave the same way. Performance tests reveal the rush-hour behavior before real users experience it.

  5 users      ───►  Server  ───►  Fast replies (120 ms)
  50 users     ───►  Server  ───►  Slower replies (450 ms)
  500 users    ───►  Server  ───►  Errors and timeouts appear

Test Types

Type	Goal	Load Shape
Smoke	Confirm the setup works	Very few users, short time
Load	Check normal expected traffic	Steady, realistic number of users
Stress	Find the breaking point	Users increase until failures start
Spike	Test sudden surges	Quick jump, then drop
Soak	Detect slow leaks	Moderate load for many hours

Run a Performance Test in Postman

1. Click a collection and choose Run.
2. Open the Performance tab.
3. Choose the number of virtual users.
4. Set the test duration.
5. Pick a load profile: fixed, ramp up, spike, or peak.
6. Select the environment.
7. Click Run.

Start small. Five virtual users for two minutes validates the setup without overwhelming a shared server.

Load Profiles

  FIXED            RAMP UP           SPIKE             
  users            users             users             
   │ ██████         │       ████      │    ██           
   │ ██████         │     ██████      │    ██           
   │ ██████         │   ████████      │ ████████        
   └────────► time  └──────────► time └────────► time   
  Same users all    Users grow        Short sudden
  the way through   step by step      jump in users

Key Measurements

Metric	Meaning
Average response time	Typical wait for one request
P90 and P95	The value below which 90 or 95 percent of requests fall
Max response time	The slowest single request
Throughput	Requests completed per second
Error rate	Share of requests that failed

Percentiles reveal more than averages. An average of 200 ms can hide a few requests that take five seconds. Watch P95 to understand what the slowest users feel.

Add Pass or Fail Rules

Tests in the collection run during the performance session. Add speed and status checks so Postman flags unacceptable results.

pm.test("Status is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response time under 1 second", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});

Read the Results

The live chart plots response time and error rate while the test runs. A healthy result keeps the response-time line flat as users increase. A line that climbs steeply shows the server reaching capacity. A jump in the error rate marks the breaking point. Note the number of virtual users at that moment.

Safe Testing Rules

• Test only servers you own or have written permission to test.
• Avoid production during busy hours.
• Use fake accounts and disposable data.
• Warn teammates before a heavy run, since shared servers slow down.
• Repeat tests after code changes to catch regressions.

Improve What You Find

• Slow database queries often explain rising response times. Ask developers to add indexes.
• Rate limit errors suggest the need for caching or higher limits.
• Memory growth in soak tests points to leaks.
• Single slow endpoints deserve their own dedicated test.

Key Points

• Performance tests measure behavior under many simultaneous users.
• Postman runs them from the Performance tab of the Collection Runner.
• Load profiles shape how users arrive over time.
• Percentiles and error rates reveal problems that averages hide.
• Test only systems you own or have permission to test.