Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon
Schedule icon

Postman Monitors Failing Assertion Runbook Sentinel

Audits Postman collection monitor test runs, detects failed response assertions, and delivers triaging runbooks to engineering on Slack.

Categories
CoreInfrastructure

Modern microservice ecosystems and public developer platforms depend on REST APIs to execute mission-critical business transactions. Engineering and Quality teams frequently automate synthetic contract testing by configuring Postman Monitors to execute Postman Collections on recurring schedules across global cloud regions. However, when upstream backend deployments introduce breaking schema modifications, missing header validations, or HTTP 500 internal errors, Postman default email notifications often land in developer spam filters or unmonitored mailing lists. As a result, API contract regressions can persist unnoticed in production for days. This sentinel queries the Postman REST API every 15 minutes, inspects the latest test run statistics for failed assertions and HTTP errors, and dispatches rich incident alerts to Slack with direct links to the Postman web execution console and triage runbooks.

How it works

  1. Scheduled triggering: Executes every 15 minutes via automated cron trigger (*/15 * * * *) or runs on-demand via manual execution.
  2. Monitor inspection query: Calls the Postman REST API endpoint /monitors/{monitor_id} using a secured Postman API key.
  3. Run statistics parsing: Evaluates lastRun.stats.assertions and lastRun.stats.requests to measure total executions versus failed counts.
  4. Threshold comparison: Verifies whether failed_assertions exceeds max_failed_assertions_threshold or if any HTTP requests experienced fatal connection drops.
  5. Conditional alerting: An io.kestra.plugin.core.flow.If flowable checks if the run recorded failures and dispatches a Slack alert to #api-contract-alerts.
  6. Manifest export: Emits a structured JSON audit payload detailing assertion metrics for API reliability scorecards and release quality gates.

Architecture diagram

flowchart TD
  A[fifteen_minute_postman_audit Schedule Trigger] --> B[evaluate_postman_monitor_run Python Script]
  B --> C[check_assertion_failures Flowable If]
  C -- Assertion Failures Detected --> D[notify_slack_postman_failure Webhook]
  C -- All Assertions Passed --> E[log_assertion_status Log]
  D --> E
  E --> F[export_postman_manifest Return]

What you get

  • Continuous verification of public and internal API contracts through automated Postman monitor checks.
  • Immediate incident dispatch to Slack with failed assertion counts, request error totals, and direct console links.
  • Elimination of unread email alerts by routing actionable notifications into dedicated engineering channels.
  • Exported JSON diagnostic manifests for tracking API contract stability and regression trends over time.

Who it's for

  • API Platform Engineers maintaining public and partner-facing REST and GraphQL endpoints.
  • QA Automation Engineers building and maintaining enterprise Postman regression test suites.
  • SREs tracking end-to-end API availability and response validation across distributed microservices.

Why orchestrate this with Kestra

Postman monitors execute scheduled test runs, but integrating those results into broader incident management and CD pipelines requires workflow orchestration. Kestra connects directly to the Postman API, evaluates assertion failure rates against custom operational thresholds, and coordinates multi-channel alerts with triaging runbooks. Using Kestra's containerized Python runner and native secret management, teams bridge the gap between testing suites and production reliability operations.

Use cases

  • API Contract Drift Protection: Detect when a backend service deployment breaks response JSON schema assumptions before frontend clients fail.
  • Partner Integration Health Verification: Monitor critical external third-party webhook and API integrations to catch vendor outages immediately.
  • Deployment Smoke Test Gate: Trigger monitor evaluation post-deployment and gate subsequent release stages based on test assertion pass rates.

Inputs

Name Type Default Description
postman_monitor_id STRING 12345678-abcd-1234-ef01-123456789abc Unique identifier UID of the target Postman collection monitor to evaluate.
max_failed_assertions_threshold INT 0 Maximum allowable failed test assertions in the most recent run before raising an incident.
alert_on_failure BOOL true Whether to dispatch automated Slack alerts when failing assertions or request errors occur.

Expected outputs

  • {{ outputs.evaluate_postman_monitor_run.vars.monitor_name }}: Display name of the evaluated Postman collection monitor.
  • {{ outputs.evaluate_postman_monitor_run.vars.failed_assertions }}: Count of failed test assertions in the latest run.
  • {{ outputs.evaluate_postman_monitor_run.vars.has_failures }}: Boolean flag indicating whether assertions or requests failed.
  • {{ outputs.export_postman_manifest.value }}: Structured dictionary containing the consolidated Postman monitor execution summary.

Prerequisites

  • Outbound HTTPS network access from Kestra execution workers to api.getpostman.com.
  • A Postman API Key (PMAK-...) with read permissions for collection monitors.
  • A Slack Incoming Webhook URL configured in Kestra secrets.

Secrets

  • POSTMAN_API_KEY: Postman API access key with permissions to read monitor run statistics.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to dispatch API contract incident notifications.

Quick start

  1. Register POSTMAN_API_KEY and SLACK_WEBHOOK_URL in your Kestra secret storage.
  2. Import this blueprint into your Kestra instance under the company.qa namespace.
  3. Update postman_monitor_id with your monitor UID (found in Postman web console URL).
  4. Run a manual execution to test Postman API authentication and verify the structured output.

Common pitfalls and troubleshooting

  • Monitor UID vs Collection UID: Ensure the input is the Monitor UID (from the Monitors tab in Postman) rather than the Collection or Workspace UID.
  • Run Latency: If the monitor runs on an hourly schedule, the sentinel evaluates the most recent completed run; ensure test runs complete within expected windows.
  • Key Rate Limits: The Postman API enforces rate limits based on team plan tiers; polling on a 15-minute interval stays well within free and enterprise quotas.

How to extend

  • Automated Re-Run Trigger: Add a downstream HTTP task to invoke POST /monitors/{monitor_id}/run to re-execute the collection upon transient network failure.
  • Jira Bug Creation: Automatically create a bug in Jira when a test assertion fails across two consecutive runs.
  • Multi-Monitor Matrix Audit: Loop over an array of monitor UIDs using io.kestra.plugin.core.flow.ForEach to audit all team test suites.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.