Every 5 minutes
Get an email when a PagerDuty incident changes
When an incident is triggered, acknowledged or resolved, you get the update with its service and urgency.
- Runs
- Every 5 minutes
- Apps
- PagerDuty
- AI
- Not needed
- Access
- read
Send this to your assistant
Create a ClickRuntime automation: every 5 minutes, check PagerDuty and email me whenever an incident is triggered, acknowledged or resolved, with the service, title, urgency and who is assigned.
First time? Adding ClickRuntime to your assistant takes about two minutes.
Why use it
Why teams use this automation
Not everyone who needs to know about a PagerDuty incident is on the escalation policy. A support lead wants to be aware that an outage was declared before customers start writing in, and an engineering manager wants to know when it resolved. Without a message, they learn it from a customer, from a chat thread that scrolled away or from someone asking whether anything is wrong.
Every five minutes, incidents changed since the previous run are listed from PagerDuty and their statuses are compared with what was seen last time. When an incident is newly triggered or newly resolved you get an email naming it, its service and its new status. An incident that has not changed stays quiet, so the inbox is not refilled with repeats.
People often use it for stakeholders who should be informed but never paged, such as customer success, account managers or a VP who wants a heads-up.
What you get out of it
Stakeholders hear it from you first
When support knows an incident started before a customer complains, replies are prepared and a status update goes out sooner. Being early is the difference between informing customers and apologizing to them.
Resolution notices close the loop
A second email when the incident resolves tells everyone the issue is over. People stop refreshing dashboards and asking in chat whether it is fixed, which saves time during and after the event.
No pager access needed
Interested people receive an email instead of being added to rotations or paid seats. You keep the escalation policy limited to responders while still widening awareness across the company. That keeps costs and clutter down for everyone.
Only real changes produce mail
Because statuses are compared against the previous check, an incident sitting unchanged for hours does not mail you again. The messages that arrive are about something new, so they get read.
A timeline you can reconstruct
Each email carries a timestamp from when it was sent. After an incident, the sequence of triggered and resolved messages gives a rough timeline for a review without digging through logs.
How it works
What happens, step by step
Every five minutes ClickRuntime checks PagerDuty for incidents created or changed since its last check.
It compares each incident's status with what it saw last time, so you only hear about real changes.
When an incident is triggered, acknowledged or resolved, you get an email with its title, service, urgency and who it is assigned to.
Before it runs live
- Connect PagerDuty
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 PagerDuty steps into one automation
Under the hood
The code that runs this automation
from datetime import datetime, timedelta, timezone
from clickruntime import on_trigger, credentials, http, notify, state, report_fetched
PD = "https://api.pagerduty.com"
def pd(path, **params):
resp = http.get(f"{PD}{path}", params=params, headers={"Authorization": f"Token token={credentials.secret('PAGERDUTY_API_KEY')}",
"Accept": "application/json"})
resp.raise_for_status()
return resp.json()
@on_trigger
def run(event):
since = (datetime.now(timezone.utc) - timedelta(days=2)).isoformat()
incidents = pd("/incidents", since=since, limit=100)["incidents"]
known = state.get("statuses") or {}
changed = [i for i in incidents if known.get(i["id"]) != i["status"]]
report_fetched(len(changed))
if not changed:
return {"changed": 0}
for i in changed:
who = ", ".join(a["assignee"]["summary"] for a in i.get("assignments", [])) or "unassigned"
notify.email_me(f"[{i['status']}] {i['title']}", f"Service: {i['service']['summary']}\nUrgency: {i['urgency']}\n"
f"Assigned: {who}\n{i['html_url']}")
known[i["id"]] = i["status"]
state.set("statuses", {i["id"]: known[i["id"]] for i in incidents if i["id"] in known})
return {"changed": len(changed)}FAQ
Common questions
How soon after an incident starts do I get the email?
Will I get an email for the acknowledged status as well?
Can it cover only the services I care about?
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 weekly incident report by service
Every Monday you see how many incidents each service had last week and how long they took to resolve on average.
See how it worksGet a reminder the day before you're on call
The afternoon before a shift, you get a note saying when your on-call starts and ends.
See how it worksGet a morning list of incidents open over a day
Every morning you see the incidents still triggered or acknowledged after 24 hours, oldest first.
See how it worksKeep exploring
Set up “Get an email when a PagerDuty incident changes” from your assistant
Copy the prompt above, or connect your assistant first. Free plan, no credit card.