An incident routine that investigates before you wake up

How this helps you

By the time you look at an alert, the evidence and a proposed fix are already gathered.

✦ Try it

Investigate [incident or alert]. Compare the current errors with releases from the last [window]. Collect the relevant logs and links. Give me: a timeline, the source links, your top hypotheses ranked by evidence, and a proposed fix. Do not change anything in production; ask me first. If data is missing or a step fails, say so plainly and stop that line of inquiry.

Fill in: [incident or alert] is the alert or issue link. [window] is how far back to look at releases, such as 48 hours.

What they did

@doublenickk laid out a setup for engineering teams. Connect your incident tools and create a routine that fires on a specific Sentry, PagerDuty or GitHub event, or a webhook. Because it runs on the Bot's cloud computer, it works with your laptop closed. The routine compares current errors with recent releases, collects relevant logs and returns a timeline, source links, hypotheses and a proposed fix, and it must get approval before any production change. Build it in order: test one investigation by hand, save the method as a skill, then automate the trigger, and define what happens when data is missing or a run fails. His warning: all your Bots share files, browser sessions and sign-ins, and giving a Bot a different name doesn't isolate its access. The 0.78.1 update lets you click a webhook routine to see its details, including the webhook URL.

Who it's for: Engineering and on-call teams already using Sentry, PagerDuty or GitHub alerts.

Before you start

Your error tracker or paging tool reachable: a connector, or a webhook it can send.
Read access to your repo and release history (GitHub).
Auto-review rules that ask first before deploys, merges or config changes.

How to try it

Pick one recent incident and ask a Bot to investigate it by hand with the prompt below.
Check the timeline and hypotheses against what really happened. Correct it.
Ask it to save the method as a skill called investigate-incident.
Create a routine that runs the skill when your chosen event or webhook fires. Open the routine to copy its webhook URL into your alerting tool.
Add the failure rules: what to do if logs are missing or a step fails.
Add Ask first rules for any production change, so the proposed fix waits for you.

What to expect

A message with a timeline from first error to now, the release that lines up with it, two or three ranked hypotheses with links, and a proposed fix waiting for approval.

Common mistakes

Automating the trigger before one hand-run investigation is right.
Assuming a separate 'incident Bot' can't reach other sign-ins. All Bots share one computer.
Letting the routine push a fix without an approval rule.

Related tips

Make routines cheaper: events, slow schedules, change checks: A 5-minute routine wakes 8,640 times a month. Use an event trigger, the slowest schedule that works, and a cheap change check.
Do it by hand, save a skill, then schedule: Most automations break because they're scheduled before they've worked once.
How the team uses its own Bot on support: It spots incidents and answers related tickets; a human approves the batch.
Set up Auto-review rules: ask first for anything you can't undo: Turn on Auto-review, then add Ask first rules for money, publishing and sending. When rules clash, Ask first wins.