Using Postman Monitors for Continuous API Health Checks

Problem: API drift goes unnoticed between releases

Teams often discover broken contracts only after a deployment fails or a user reports an error. By the time the issue is caught, the faulty version may already be live, causing downtime or data corruption. What you need is a way to continuously validate that your API behaves as expected, without setting up a full‑blown CI pipeline.

Thesis: Postman Monitors give you lightweight, scheduled validation without extra infrastructure

Monitors run your existing Postman collections on a schedule using Postman’s cloud infrastructure. They execute requests exactly as they appear—including pre‑request and test scripts—collect results, and can trigger alerts when something goes wrong. Because they reuse the same collection you already use for manual testing, there is no duplication of effort.

How a monitor works

When you create a monitor you choose:

• The collection (or folder) to run.
• The schedule (e.g., every 5 minutes, hourly, daily).
• Optional environment or global variable overrides, letting you point the same collection at dev, staging, or prod.
• Alert conditions based on success rate, response time, or specific test failures, with notifications via email, Slack, or webhook.

Each run produces a record in the monitor’s history showing timestamp, outcome, and response times.

Worked example: monitoring a public endpoint

1. In Postman, create a new collection called "Health Check". Add a GET request to https://httpbin.org/status/200.
2. Select the request’s "Tests" tab and paste the following script:

pm.test("Status code is 200", function () {
    pm.expect(pm.response.code).to.equal(200);
});

1. Save the collection.
2. Click the "Monitors" tab in the left sidebar, then "Create a monitor".
3. Choose the "Health Check" collection, set the schedule to "Every 5 minutes", and leave environment overrides blank.
4. Under "Alert settings", enable "Send an email when the success rate drops below 100 %" and add your email address.
5. Click "Create monitor".

After a few minutes you can verify the monitor is working:

1. Open the monitor’s detail page and look at the "Latest run" section; you should see a timestamp within the last five minutes and a green check‑mark indicating success.
2. Check your email inbox for a confirmation that no alert was sent (since the test passes).
3. To test the alert path, edit the test script to expect status 404, save the collection, and wait for the next monitor run. You should receive an alert email shortly after the run finishes, and the monitor history will show a red failure for that run.

Trade‑offs and limitations

• API call quota: Each monitor run consumes calls against your Postman plan’s limit. A high‑frequency monitor on a large collection can exhaust the quota quickly, leading to extra charges or throttling.
• No persistent state across runs: Variables set with pm.environment.set in a pre‑request or test script are reset for each iteration. If you need to share data between runs (e.g., a token that expires), you must store it externally or use a persistent environment variable that you update outside the monitor.
• Limited to Postman’s cloud: Monitors cannot run on self‑hosted runners; if you require execution inside a private network for security reasons, you must rely on IP allow‑listing or a hybrid approach.

Checking that it works

Beyond the manual steps above, you can programmatically verify a monitor’s health via the Postman API:

GET https://api.getpostman.com/monitors/{monitorId}/runs?limit=1
X-Api-Key: {{postmanApiKey}}

The response includes the most recent run’s state (completed, failed, etc.) and responseTime. If the state is not "completed" or the response time exceeds your threshold, you know something is wrong.

Actionable next steps

• Start with a small, high‑value collection (e.g., health‑check or contract‑validation) and create a monitor that runs every 15 minutes.
• Monitor the quota usage in your Postman dashboard to adjust frequency or collection size as needed.
• If you need to persist data between runs, design an external store (such as a key‑value service) and update it from the test script using pm.sendRequest.