Weekly
Chase unfinished post-incident follow-ups
Every week you get the follow-ups still outstanding, grouped by owner, with how long each has been open.
- Runs
- Weekly
- Apps
- incident.io
- AI
- Not needed
- Access
- actions.view
Send this to your assistant
Create a ClickRuntime automation: every Monday at 8am email me all incident.io follow-ups that are still outstanding, grouped by assignee, showing how many days old each one is.
First time? Adding ClickRuntime to your assistant takes about two minutes.
Why use it
Why teams use this automation
After every serious incident, the on-call team and the responders meet and agree on follow-ups: add an alert, fix the retry bug, update the runbook. Those items are recorded in incident.io, and then ordinary work takes over. Three months later the same failure happens again because the action items from the last post-mortem were never completed, and the post-incident review quietly turns out to have changed nothing for the customers who were affected.
Each week, ClickRuntime lists the follow-ups in incident.io, keeps the ones that are not finished, groups them by assignee and shows how old each is. It then emails the list, so every owner and their manager can see what is open from past incidents and for how long.
It is aimed at engineering leaders and reliability teams who want post-mortems to lead to real fixes.
What you get out of it
Post-mortems lead to actual fixes
An action item that no one is reminded about tends to stay open forever. A weekly list makes unfinished follow-ups visible, which is how the retry bug gets fixed before it causes the same outage again.
Repeat incidents become less likely
Many outages are repeats of earlier ones whose fixes were never completed. Closing out follow-ups reduces repeat failures, which means fewer pages at night, fewer apologies to customers and fewer repeat reviews.
Age exposes the neglected items
A follow-up that is 90 days old tells a different story from one that is 4 days old. Showing age lets managers prioritize the ones that have been ignored longest, and ask whether they are still relevant.
Accountability without a meeting
Grouping by assignee puts each person's open items next to their name. Nobody has to run a status round to learn who is behind, and the conversation can move straight to what is blocking them.
Audit evidence for reliability programs
Customers, security reviewers and auditors increasingly ask how you learn from incidents. A history of weekly lists showing follow-ups being assigned and closed is concrete proof that your learning process works as described.
How it works
What happens, step by step
Once a week, ClickRuntime pulls every post-incident follow-up from incident.io.
It keeps only the ones still marked outstanding and works out how many days each has been open.
Follow-ups are grouped under the person they're assigned to, with unassigned ones in their own group.
You get one email listing each owner and their open follow-ups, like "Document EU failover runbook (5 days)".
Before it runs live
- Connect incident.io
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 incident.io steps into one automation
Under the hood
The code that runs this automation
from collections import defaultdict
from datetime import datetime, timezone
from clickruntime import on_trigger, credentials, http, notify
IO = "https://api.incident.io"
def io(path, **params):
resp = http.get(f"{IO}{path}", params=params, headers={"Authorization": f"Bearer {credentials.secret('INCIDENT_IO_API_KEY')}"})
resp.raise_for_status()
return resp.json()
@on_trigger
def run(event):
follow_ups = io("/v2/follow_ups")["follow_ups"]
groups = defaultdict(list)
for f in follow_ups:
if f["status"] != "outstanding":
continue
age = (datetime.now(timezone.utc) - datetime.fromisoformat(f["created_at"].replace("Z", "+00:00"))).days
groups[(f.get("assignee") or {}).get("name", "Unassigned")].append(f" {f['title']} ({age} days)")
body = "\n".join(f"{who}\n" + "\n".join(items) for who, items in sorted(groups.items()))
notify.email_me(f"{sum(len(v) for v in groups.values())} outstanding incident follow-ups", body or "All done.")
return {"assignees": len(groups)}FAQ
Common questions
What counts as an outstanding follow-up?
Can I see only follow-ups from high-severity incidents?
What happens to follow-ups that have no assignee?
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 severity
Each Monday you see last week's incidents grouped by severity, with status and how long each lasted.
See how it worksGet an email when an incident is declared
Within a few minutes of a new incident in incident.io, you get an email with its name and severity.
See how it worksSend a short recap when an incident is resolved
Once an incident closes, stakeholders get a plain summary of what happened, built from its updates.
See how it worksKeep exploring
Set up “Chase unfinished post-incident follow-ups” from your assistant
Copy the prompt above, or connect your assistant first. Free plan, no credit card.