Postman Monitors: Scheduling API Health Checks and Alerts

Always-On API Confidence

Deploying a feature and running a test suite are two different things from running that suite continuously. A change that works at 14:00 can break at 02:00 when a background job touches a shared database or a third-party token expires. Postman Monitors close that gap: they execute your collections on a cron-like schedule from Postman's cloud infrastructure, require zero servers on your end, and alert you when something goes wrong.

This post covers how Monitors work, how to configure schedules and alert policies, and how to write monitor scripts that catch real problems rather than just confirming the endpoint responds.

What Postman Monitors Are and How They Work

A Monitor is a scheduled execution of a Postman collection, tied to a specific environment. Postman's cloud infrastructure runs the collection on your chosen cadence — every 5 minutes, hourly, daily, or on a custom cron schedule — from one or more geographic regions.

Each monitor run:

1. Spins up an isolated runner
2. Resolves the linked environment's variables
3. Executes every request in the collection, in order
4. Evaluates all pre-request and test scripts
5. Records the result: pass/fail counts, response times, error messages
6. Stores the run in the monitor's history log
7. Fires alerts if the configured failure threshold is met

Because monitors run in Postman's cloud, they exercise your API from an external network perspective — the same vantage point your users have. This catches firewall misconfigurations, CDN routing issues, and region-specific outages that internal health checks would miss.

What counts toward usage: Monitor runs are billed against your plan's monitor call quota. A collection with 10 requests running every 5 minutes consumes 10 × 288 = 2,880 calls per day. Check your plan before setting aggressive schedules.

Setting Up Monitor Schedules

Creating a Monitor

In Postman, open your collection and select Monitors → Create a monitor (or use the Monitors tab in the left sidebar). The setup screen asks for:

• Collection — the collection to run
• Environment — which variable set to use
• Schedule — frequency and time zone
• Regions — where to run from (US East, EU West, Asia Pacific, etc.)

Schedule Options

Postman supports two schedule modes:

Fixed intervals: every 5 minutes, 15 minutes, 30 minutes, 1 hour, 6 hours, or 24 hours.

Custom cron: available on paid plans, using standard 5-field cron syntax:

┌─────────── minute (0-59)
│  ┌──────── hour (0-23)
│  │  ┌───── day of month (1-31)
│  │  │  ┌── month (1-12)
│  │  │  │  ┌ day of week (0-6, Sunday=0)
│  │  │  │  │
*  *  *  *  *

Examples:

0 9 * * 1-5      # 09:00 UTC, weekdays only
*/15 * * * *     # every 15 minutes
0 */6 * * *      # every 6 hours
30 2 * * *       # 02:30 UTC daily (off-peak synthetic check)

Multi-Region Monitoring

Running from a single region tells you your API is reachable from one point. Running from three regions tells you whether routing is consistent globally. Add regions in the monitor settings — each region runs the full collection independently and reports separately. If US East passes but EU West fails, you immediately have a geographic signal rather than an ambiguous global failure.

Alert Policies and Notification Channels

Failure Thresholds

Monitors do not alert on the first failure by default — transient network blips would create noise. Configure a failure threshold (e.g., alert after 2 consecutive failures) to filter out one-off errors while still catching real outages within two run cycles.

Options typically available:

• On every failure — maximum sensitivity, more noise
• After N consecutive failures — recommended for production APIs
• When error rate exceeds X% — useful for high-frequency monitors

Email Notifications

By default, monitor alerts go to the email address of the workspace owner. Add additional recipients in the monitor's Notification settings. You can add team email addresses or a group alias like api-oncall@example.com.

The alert email includes:

• Monitor name and collection
• Run timestamp and region
• Number of failed tests
• Link to the specific run in the Monitors dashboard

Slack Integration

Connect Slack in Postman Settings → Integrations → Slack. Once connected, configure the monitor to post to a specific channel:

1. Open the monitor → Integrations tab
2. Add the Slack integration
3. Choose a channel (e.g., #api-alerts)
4. Optionally configure a custom message template

A failure alert in Slack looks like:

🔴 Monitor Failed: Checkout API Health
Collection: E-Commerce API
Region: US East
Failed tests: 2/8
Time: 2026-06-01 14:35 UTC
View run: https://go.postman.co/monitors/...

Recovery alerts fire automatically when a subsequent run passes — 🟢 Monitor Recovered: Checkout API Health — so your team knows when to stop investigating without manually rechecking the dashboard.

PagerDuty and Webhook Integrations

For on-call escalation, Postman integrates with PagerDuty and OpsGenie via the Integrations panel. You can also use a generic Webhook integration to POST run results to any endpoint — useful for routing alerts through your own incident management system or appending run data to a time-series database.

Dashboard Overview and History

The Monitors dashboard (accessible from the left sidebar in Postman or go.postman.co/monitors) shows:

• Pass rate — percentage of successful runs over the selected time window (24h, 7d, 30d)
• Response time graph — p50, p90, p95 lines overlaid on the timeline
• Run history — every run, with pass/fail counts and timestamps
• Region breakdown — per-region pass rates for multi-region monitors

Clicking any run opens a full execution log: request headers, response bodies, test results, and console output — the same view you get in Newman's verbose output, but stored and searchable in Postman's cloud.

Using response time trends: A p95 response time that is climbing week-over-week is a leading indicator of degradation even if your tests are still passing. Set a threshold test (see below) so that slow responses count as failures, not just slow successes.

Best Practices for Monitor Scripts

Monitor scripts use the same pm.* API as regular collection tests. Here are patterns that make monitors genuinely useful rather than superficially green.

Assert Response Time, Not Just Status

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

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

A 200 response that takes 8 seconds is not healthy. Always pair a status assertion with a response time assertion calibrated to your SLO.

Validate Response Shape

pm.test("Response contains required fields", function () {
    const body = pm.response.json();
    pm.expect(body).to.have.property("id");
    pm.expect(body).to.have.property("status");
    pm.expect(body.items).to.be.an("array").with.length.above(0);
});

An API that returns {} with a 200 status is broken. Schema validation catches regressions that a status check misses.

Chain Requests with Variables

Pass data between requests to test multi-step flows:

// In "POST /orders" test script:
const order = pm.response.json();
pm.collectionVariables.set("latestOrderId", order.id);

// In "GET /orders/{{latestOrderId}}" test script:
pm.test("Order is retrievable", function () {
    pm.response.to.have.status(200);
    pm.expect(pm.response.json().id).to.eql(
        pm.collectionVariables.get("latestOrderId")
    );
});

This tests the full create-then-read flow, not just that the endpoint exists.

Keep Monitors Idempotent

Monitors run continuously, so every run must leave your system in the same state it found it. Prefer read-only requests for health checks. If you need to test a write path, add teardown requests at the end of the collection to clean up created resources. Never let a monitor accumulate test data in production databases.

Use Pre-Request Scripts for Token Refresh

// Pre-request script on any authenticated request:
const tokenExpiry = pm.collectionVariables.get("tokenExpiry");
const now = Date.now();

if (!tokenExpiry || now > parseInt(tokenExpiry)) {
    // Token is missing or expired — fetch a new one
    pm.sendRequest({
        url: pm.variables.get("baseUrl") + "/auth/token",
        method: "POST",
        header: { "Content-Type": "application/json" },
        body: {
            mode: "raw",
            raw: JSON.stringify({
                client_id: pm.variables.get("clientId"),
                client_secret: pm.variables.get("clientSecret")
            })
        }
    }, function (err, res) {
        const data = res.json();
        pm.collectionVariables.set("accessToken", data.access_token);
        pm.collectionVariables.set("tokenExpiry", now + (data.expires_in * 1000));
    });
}

Without token refresh logic, a monitor will fail every time a short-lived token expires — generating false alerts that train your team to ignore the noise.

Distinguish Between Alert-Worthy and Informational Tests

Not every assertion needs to be an alert-triggering failure. Use console.log for observational data:

const p99 = pm.response.responseTime;
console.log(`Response time: ${p99}ms`);

pm.test("Latency SLO: under 300ms (p95 target)", function () {
    pm.expect(p99).to.be.below(300);
});

The log appears in the run history regardless of pass/fail. The test controls whether the run counts as a failure for alerting purposes.

A Practical Monitor Setup for a Production API

Here is a concrete structure for a production API monitor:

Collection: "Production Health — E-Commerce API"
├── Auth (Pre-request: fetch token if expired)
├── GET /products              → status 200, body has items[], time < 300ms
├── GET /products/{{productId}}→ status 200, valid product schema
├── POST /cart                 → status 201, returns cartId
├── GET /cart/{{cartId}}       → status 200, matches created cart
├── DELETE /cart/{{cartId}}    → status 204 (cleanup)
└── GET /health                → status 200, {"status":"ok"}

Schedule: every 5 minutes
Regions: US East, EU West
Alert: after 2 consecutive failures
Channel: #api-oncall (Slack)

This runs 6 requests every 5 minutes from two regions — 12 API calls per run, 3,456 per day. It tests the critical happy path end-to-end, not just a ping endpoint, and cleans up after itself.

Wrapping Up

Postman Monitors turn your collection from a one-shot test into a continuous signal. The setup cost is low — link a collection, pick a schedule, add a Slack channel — and the payoff is immediate visibility into API health between deployments. The key discipline is writing monitor scripts that catch real failures: schema regressions, latency degradation, and auth expiry, not just "did the endpoint return 200".

Once monitors are running, the next step is handling more complex scenarios: conditional branching, fan-out API calls, and no-code workflow orchestration. That is where Postman Flows comes in.