Weekly
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.
- Runs
- Weekly
- Apps
- PagerDuty
- AI
- Not needed
- Access
- read
Send this to your assistant
Create a ClickRuntime automation: every Monday at 9am, email me last week's PagerDuty incidents grouped by service, with the count and mean time to resolve for each.
First time? Adding ClickRuntime to your assistant takes about two minutes.
Why use it
Why teams use this automation
Ask an engineering director how reliable last week was and the honest answer is usually a shrug. The data exists in PagerDuty, but pulling it means exporting incidents, grouping them by service in a spreadsheet and working out how long each took to resolve. Most weeks nobody does it, so a service that pages the team every night goes unnoticed until people are burnt out.
Once a week, incidents from the past seven days are listed from PagerDuty and grouped by service. For each service the count is shown along with the mean time to resolve, calculated from created and resolved times, and the result arrives in one email. The numbers come from the same incident records your responders already work in.
It works well as a Monday review for a platform team, and for managers who need a simple trend line to show leadership without building a dashboard.
What you get out of it
See which service pages the most
A count per service names the noisiest system in plain numbers. Teams can then argue about fixing that service instead of about whose gut feeling about reliability is right. That clarity makes prioritizing much easier.
Mean time to resolve as a trend
Seeing MTTR every week shows whether response is getting faster or slower. A creeping increase is an early sign of understaffing, weak runbooks or a service that has become harder to debug.
A record for reviews and audits
Weekly summaries accumulate into a searchable history in your inbox. When a quarterly review or a customer asks about reliability, the figures are already there and need no reconstruction from memory.
Justify fixing the boring problems
A service with forty incidents in a week makes a convincing case for engineering time. The report turns a vague complaint about alert fatigue into evidence a planning meeting can act on.
Protect on-call people from burnout
When one team absorbs most of the pages, it shows in the counts. Managers can rebalance ownership or add a rotation before people start leaving because of nights spent on the same recurring alert.
How it works
What happens, step by step
Every Monday ClickRuntime gets last week's PagerDuty incidents.
It groups them by service.
It works out the average time each service took to resolve its incidents.
The report arrives in your inbox, one line per service.
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
- Run it at a different time, more or less often, or only on weekdays
- 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 collections import defaultdict
from datetime import datetime, timedelta, timezone
from clickruntime import on_trigger, credentials, http, notify
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()
def ts(s):
return datetime.fromisoformat(s.replace("Z", "+00:00"))
@on_trigger
def run(event):
until = datetime.now(timezone.utc)
incidents = pd("/incidents", since=(until - timedelta(days=7)).isoformat(), until=until.isoformat(), limit=100)["incidents"]
by_service = defaultdict(list)
for i in incidents:
by_service[i["service"]["summary"]].append(i)
lines = []
for service, items in sorted(by_service.items(), key=lambda kv: -len(kv[1])):
resolved = [(ts(i["resolved_at"]) - ts(i["created_at"])).total_seconds() / 60 for i in items if i.get("resolved_at")]
mttr = f"{sum(resolved) / len(resolved):.0f} min" if resolved else "n/a"
lines.append(f"{service}: {len(items)} incidents, MTTR {mttr}")
notify.email_me(f"PagerDuty last week: {len(incidents)} incidents", "\n".join(lines))
return {"incidents": len(incidents)}FAQ
Common questions
Does it count low-urgency incidents too?
How is time to resolve calculated for incidents still open?
Will it work if we have dozens of services?
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 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 worksGet an email when a PagerDuty incident changes
When an incident is triggered, acknowledged or resolved, you get the update with its service and urgency.
See how it worksKeep exploring
Set up “Get a weekly incident report by service” from your assistant
Copy the prompt above, or connect your assistant first. Free plan, no credit card.