Postman Monitors

A collection run proves that an API works right now. A monitor proves that it keeps working all day. Postman monitors run collections on a schedule from cloud servers and report failures by email or chat message. Teams learn about broken endpoints before customers do.

The Night Watchman Idea

A night watchman walks the same route every hour and checks each door. Nobody asks the watchman to patrol; the schedule handles it. A monitor follows the same pattern. It visits every request in a collection at fixed times and records what it finds.

  SCHEDULE            COLLECTION RUN           RESULT
  ────────            ──────────────           ──────
  Every hour   ───►   Login → Orders → Pay ───► All tests pass
  Every hour   ───►   Login → Orders → Pay ───► Tests FAIL ──► Alert sent
  Every hour   ───►   Login → Orders → Pay ───► All tests pass

What a Monitor Needs

• A collection with tests that define success.
• An environment with the correct server addresses.
• A schedule, such as every five minutes, hourly, or daily.
• A notification target, such as email addresses or a chat integration.

Create a Monitor

1. Hover over a collection and open the three-dot menu.
2. Select Monitor collection or open the Monitors tab.
3. Type a clear monitor name.
4. Choose the environment.
5. Set the run frequency and the time zone.
6. Add the email addresses for failure alerts.
7. Click Create.

Postman schedules the first run and displays results on the monitor page.

Write Tests That Matter

A monitor reports only what the tests check. A collection without tests always reports success as long as the server answers. Add assertions for status codes, important fields, and speed.

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

pm.test("Response arrives within 800 ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(800);
});

pm.test("Orders list exists", function () {
    pm.expect(pm.response.json()).to.have.property("orders");
});

Read the Monitor Dashboard

Dashboard Area	What It Shows
Run history chart	Passes and failures over time
Response time graph	Speed trends for every run
Failed tests list	Names and error messages of broken checks
Console log	Output from console.log statements in scripts
Run details	Each request with its response and test results

Regions and Reliability

Postman can run monitors from several geographic regions. Multi-region runs reveal problems that affect only some countries, such as a slow network route. A single failure from one region may signal a local network glitch. Failures from every region signal a real outage.

Alerts and Integrations

Email works for small teams. Larger teams connect monitors to tools such as Slack, Microsoft Teams, PagerDuty, or a custom webhook. Choose whether alerts fire after one failure or after several consecutive failures. A threshold of two or three failures reduces false alarms from brief hiccups.

Handle Secrets in Monitors

Monitors run in the cloud, so they cannot read your local vault or current values. Place the values a monitor needs in the environment's initial value column. Use a dedicated test account with limited permissions, and never reuse a personal production key.

Monitor Planning Example

  Monitor 1: Health Check
    Collection : GET /health
    Frequency  : every 5 minutes
    Goal       : detect outages quickly

  Monitor 2: Core Business Flow
    Collection : Login → Create Order → Pay
    Frequency  : every hour
    Goal       : confirm the main journey works

  Monitor 3: Nightly Regression
    Collection : Full test suite
    Frequency  : once per night
    Goal       : catch quiet breakage after code changes

Best Practices

• Monitor production health endpoints and staging full flows.
• Clean up data that monitor runs create, such as test orders.
• Keep monitor collections small and fast to save run quota.
• Review the dashboard weekly for slow response trends.
• Update monitors whenever an API changes.

Key Points

• Monitors run collections on a schedule from the cloud.
• Tests inside the collection define what counts as failure.
• Dashboards show pass rates and response time trends.
• Alerts reach teams by email or chat tools.
• Monitors use initial values, so keep test secrets limited and separate.