Your progress is saved locally. to save it permanently.

0 of 2 steps0%

With a collection and an environment in place, you can hand them to a monitor. Postman then owns the running of it — on a schedule, from its own infrastructure, whether or not your laptop is open. The New monitor form sets it all up in one screen; after that you'll tune a single advanced setting.

1

Create the monitor

This is the moment the collection stops being something you run by hand. The New monitor form is a single screen — most of it is sensible defaults, so you're mostly confirming: name the monitor, point it at your collection and environment, set a schedule, and turn on failure alerts, all before you click Create Monitor.

  1. Click the Services tab in the left sidebar.
  2. Click +, then select Monitor from the dropdown list.
  3. Enter the Monitor name:
text
Coffee API Health Check Monitor
  1. For Collection, select Coffee API Health Check.
  2. For Environment, select Monitoring — without it, {{baseUrl}} can't resolve in the cloud and every run errors.
  3. Under Run method, leave Schedule selected (it's the default) and pick a frequency from the dropdowns — Every hour or Every day at a fixed time both work on any plan.
  4. Leave Runners on Auto-select — Postman picks one for you. Choosing specific regions by hand requires a paid plan, and one runner is plenty here.
  5. Under Notifications, keep Receive email notifications for run failures and errors checked and enter your email address (up to five recipients). Leave the consecutive-failure limit at 3 so a permanently broken endpoint doesn't flood your inbox.
  6. Click Create Monitor.

Choose your interval from what the API is for, not from what feels thorough:

IntervalGood for
Every 5 minutesPublic status pages and revenue-critical endpoints (paid plans only)
Every hourMost production APIs
Every dayInternal or low-traffic services
Every weekRarely-changing endpoints and smoke checks
Note: Only paid plans can schedule minute-based runs — on the Free plan, pick an hourly or daily frequency. Prefer to trigger runs from your pipeline instead? Switch Run method to Postman CLI and run the monitor from CI/CD after a deploy.

Once a failing monitor passes again, Postman sends a recovery email. Prefer chat over email? Check Notify a Slack or Microsoft Teams channel or chat and connect your workspace.

Expected outcome: The monitor appears under Monitors in the Services sidebar with an Unknown status — an empty circle just means it hasn't run yet, not that anything is wrong.

Troubleshooting: Monitors don't support OAuth 2.0 authentication. This collection needs no auth at all, so you shouldn't hit that here — but keep it in mind for your own APIs.

You can also create a monitor with the Postman API if you'd rather automate it.

2

Set a request timeout

Monitors run their requests in order, never in parallel, and a run that's still going when the next one is due will block it. A request timeout puts a ceiling on that, so one hung endpoint can't quietly create gaps in your monitoring history.

  1. With your monitor open, click More actions > Edit.
  2. Go to Advanced Settings.
  3. Select Set request timeout and enter a value in milliseconds:
10000
  1. Click Update Monitor.
Note: The field pre-fills at 5000 ms, so enter a different value like 10000 — LiftOff only counts a timeout you've deliberately changed.

While you're in Advanced Settings, it's worth knowing what the other options do:

SettingWhat it does
Retry if run failsRe-runs a failed request automatically to absorb transient blips. Counts extra requests toward your usage.
Set request timeoutCaps how long the whole run may take. Max 10 minutes (600000 ms) on Free, 15 minutes (900000 ms) on paid plans.
Set delay before requestsInserts a pause before each request, for rate-limited APIs.
Follow redirectsOn by default — the monitor follows HTTP redirects.
Enable SSL validationOn by default. Turn off only for self-signed certificates.

Caution: The timeout applies to the entire monitor run, including every request, response, and script — not per request. Don't set it lower than the run realistically needs.