Every 15 minutes
Hear about failed monitor runs in Slack
When a monitor run fails, your channel gets one message about it, not a repeat on every check.
- Runs
- Every 15 minutes
- Apps
- Postman
- AI
- Not needed
- Access
- read
Send this to your assistant
Create a ClickRuntime automation: every 15 minutes, check my Postman monitors and post any failed run to #api-alerts in Slack, once per failure.
First time? Adding ClickRuntime to your assistant takes about two minutes.
Why use it
Why teams use this automation
When a Postman monitor fails, the failure is recorded in Postman and that is the end of it. Unless somebody happens to be looking at the monitor page, it goes unseen. A broken authentication endpoint or a response that exceeds a latency assertion can run for hours, and the first sign is often a customer complaint, or an angry message in the support queue on Monday morning.
Every 15 minutes, the latest run statistics are fetched for each monitor. If a run has failures, a message is posted to Slack, once for each failing run, so the same failure is not repeated every time the check repeats. The team hears about a broken API within minutes of the monitor catching it, with the monitor name and failure count.
It suits teams that depend on Postman monitors for uptime checks but have no separate paging tool yet.
What you get out of it
Failures reach the team within minutes
A Slack message at the next check means people know soon after the monitor catches the problem. That shortens the window during which customers hit errors and the team is unaware.
One message per failure, not a flood
Each failing run is reported once, so a long outage does not bury the channel. The team sees the start of the problem and can discuss it in a single thread.
Fix it before customers write in
Resolving an incident before users notice protects trust. Many outages never become support tickets when they are repaired within the hour that a monitor first flagged them. Customers rarely notice what is fixed fast.
Monitors you already built start paying off
Existing Postman monitors become active alerts without new tooling or another subscription. The checks that engineers wrote carefully finally reach the people who can act on them. Nothing else needs to be bought or installed.
A timestamped history of failures
Each message records when a failure was noticed. When writing up an incident, that trail shows when the problem began and how long it took to get attention. Later reviews are far easier with that record.
How it works
What happens, step by step
Every 15 minutes, ClickRuntime checks the latest run of each of your Postman monitors.
When a run has failed checks, it looks at whether it has already reported that run.
New failures are posted to #api-alerts with the monitor name, time and number of failed checks. The same failed run is never posted twice.
Before it runs live
- Connect Postman
What you get
Build your own
Need it to work differently?
Your own rules
Conditions, thresholds, filters and exceptions, written the way you'd explain them to a colleague.
Any number of apps
One automation can read from one app and update several others. Over 248 apps are ready, and anything with an API works too.
AI where it helps
Summaries, classification, extraction and drafts use ClickRuntime's built-in AI, with no extra key.
On a schedule or on each event
Runs as often as every 5 minutes, or the moment an app sends an event, and keeps track of what it already handled.
Changes you can ask for
- Act only on the items that match your own rules, and skip the rest
- Add an AI step, for example to summarize, sort or draft a reply
- Add another app, for example also send it to Slack
- Combine it with other Postman steps into one automation
Under the hood
The code that runs this automation
from clickruntime import on_trigger, credentials, http, notify, state, report_fetched
API = "https://api.getpostman.com"
@on_trigger
def run(event):
headers = {"X-Api-Key": credentials.secret("POSTMAN_API_KEY")}
seen = state.get("seen_failures") or {}
new = []
for m in http.get(f"{API}/monitors", headers=headers).json()["monitors"]:
last = http.get(f"{API}/monitors/{m['uid']}", headers=headers).json()["monitor"].get("lastRun") or {}
if last.get("status") == "failed" and seen.get(m["uid"]) != last.get("finishedAt"):
new.append((m, last))
report_fetched(len(new))
if not new:
return {"failed": 0}
for m, last in new:
failed = last.get("stats", {}).get("assertions", {}).get("failed", 0)
notify.slack(f"Postman monitor *{m['name']}* failed at {last['finishedAt'][:16]} "
f"({failed} assertions failed)", channel="#api-alerts")
seen[m["uid"]] = last["finishedAt"]
state.set("seen_failures", seen)
return {"failed": len(new)}FAQ
Common questions
What counts as a failure here?
Why check every 15 minutes?
Will I be told when it recovers?
What permissions does it need?
Does it need AI?
How many runs does it use?
Can I change how it works?
Related
You might also like
Get a morning report on your Postman monitors
Every day you get one email listing each monitor, whether its last run passed, and how fast it responded.
See how it worksSee which collections changed this week
On Monday you get a list of the collections in your workspace that were edited during the past seven days.
See how it worksBack up your Postman collections every week
Each Sunday a JSON export of every collection in the workspace arrives in your inbox.
See how it worksKeep exploring
Set up “Hear about failed monitor runs in Slack” from your assistant
Copy the prompt above, or connect your assistant first. Free plan, no credit card.