What Are Postman Monitors?
A Postman Monitor takes an existing collection and schedules it to run automatically and repeatedly — as often as every 5 minutes — from Postman's own cloud infrastructure, with no developer machine or open Postman window required. This turns a collection you already trust from manual testing into an ongoing, unattended production health check.
Cricket analogy: A Postman Monitor is like a stadium's automated pitch-moisture sensor that checks conditions every hour on match days, alerting groundstaff long before anyone walks out to inspect it manually.
Creating and Scheduling a Monitor
Creating a monitor lets you pick a schedule ranging from every 5 minutes up to a custom cron-like interval, choosing a frequency that matches how quickly you need to know about an outage versus how much monitor-run quota you're willing to spend. High-traffic or revenue-critical endpoints typically warrant tighter schedules than internal or low-priority ones.
Cricket analogy: Scheduling a monitor to run every 15 minutes is like a physio checking a bowler's workload count every session rather than waiting for the end-of-series review, catching overuse early.
curl -X POST \
https://api.getpostman.com/monitors/12345678-abcd-1234-efgh-1234567890ab/run \
-H "X-Api-Key: $POSTMAN_API_KEY"Choosing Regions and Frequency
Monitors can be configured to execute from multiple geographic regions (such as US East, EU West, or Asia South) rather than a single location, which surfaces problems that only show up in specific parts of your infrastructure — a regional CDN edge, a database read replica, or a network path issue that a single-region check would never catch.
Cricket analogy: Choosing to run a monitor from both Mumbai and Sydney data centers is like sending scouts to check pitch conditions at both an away and home venue before a touring series, so no regional surprise goes unnoticed.
Alerts, Uptime, and Monitor Results
When a scheduled run fails an assertion or exceeds a configured threshold, Postman can immediately notify configured recipients by email or via connected integrations, so a real problem reaches an on-call engineer within minutes instead of being discovered when a customer files a support ticket. The monitor's run history also builds an uptime and response-time trend over time, useful for spotting slow degradation, not just hard outages.
Cricket analogy: Getting an email alert the moment a monitor fails is like a coach getting an instant text when a bowler's speed drops below a threshold mid-spell, rather than finding out from the highlights reel afterward.
Monitors run the exact same collection and test scripts used in Collection Runner and Newman, so a monitor failure surfaces the same pm.test() assertions you already wrote — there's no separate monitor-specific scripting language to learn.
Each monitor run counts against your Postman plan's monthly monitor-execution quota. Running a monitor every minute from three regions multiplies usage fast — check your plan's limits before scheduling aggressively.
- A Postman Monitor runs a saved collection on a recurring schedule (as often as every 5 minutes) without any user opening Postman.
- Monitors execute the same requests and pm.test() assertions already defined in the collection.
- You can select one or more cloud regions to run a monitor from, catching region-specific latency or availability issues.
- Failed monitor runs trigger email (or integrated) alerts to configured recipients.
- Monitor run history shows uptime percentage, response times, and per-run pass/fail results over time.
- Each monitor execution counts against a plan's monitor-run quota, so frequency and region count should be chosen deliberately.
Practice what you learned
1. What powers the pass/fail logic of a Postman Monitor run?
2. Why would you run a monitor from multiple regions instead of just one?
3. What happens when a scheduled monitor run fails an assertion?
4. What should you consider before scheduling a monitor to run every 5 minutes from 4 regions?
Was this page helpful?
You May Also Like
Collection Runner
Learn how Postman's Collection Runner executes an entire collection of requests in sequence, complete with data-driven iterations, delays, and detailed pass/fail reporting.
Postman/Newman in CI/CD Pipelines
Integrating Postman collections into CI/CD pipelines via Newman lets teams catch API regressions automatically on every commit, before code reaches production.
Newman: Running Collections from the CLI
Newman is Postman's command-line collection runner, letting teams execute collections, generate reports, and fail builds without opening the Postman app.