# Daily on-call handoff brief from Better Stack to Slack

> At every shift change, an agent turns overnight incidents, uptime numbers, and recent merges into one short brief for the incoming on-call engineer.

- Workflow type: agent
- Services: Better Stack, GitHub, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-14

## What it does

- Works out who is picking up the pager and who just handed it over, straight from your on-call schedule, and names both people in the brief.
- Pulls the last 24 hours of incidents, flags anything still open, acknowledged late, or reopened, and attaches real uptime percentages for the services that were involved.
- Lines up everything merged into your main branch since the previous shift began against incident start times, so likely culprits get called out by name instead of guessed at later.
- Sends the brief as a direct message to the incoming engineer and posts the same thing to your team reliability channel, so context is never trapped with one person.

## What you'll need

- A Better Stack account with monitors and at least one on-call schedule set up
- A GitHub account with access to the repositories your team ships from
- A Slack workspace and a channel where your team reads reliability updates
- On-call engineers' email addresses matching between Better Stack and Slack, so the right person gets the direct message

## Prompt

Every morning at 9am, right when my on-call rotation changes hands, build a handoff brief for whoever is picking up the pager and deliver it in Slack. Use a scheduled trigger rather than an incident webhook, because this is tied to the shift boundary and not to any one alert firing. Make the schedule easy to retime so it can match our actual rotation boundary, and run it all seven days since we have weekend rotations.

Start in Better Stack. Use List On-call Schedules to find our rotation, then Get On-call Schedule to work out who is on call right now and who just came off. Name both people in the brief, the outgoing engineer and the incoming one.

Then use List Incidents filtered to the last 24 hours. Separate the incidents that are still unresolved from the ones that were closed out. For anything that was acknowledged late or reopened, call List Incident Timeline so the brief can say what actually happened: when it fired, how long it sat unacknowledged, who it escalated to, and when it resolved.

For the monitors involved in those incidents, call Get Monitor Availability (SLA) so the brief carries real uptime numbers instead of vague statements like mostly stable. Use List Monitors if you need to resolve monitor names or ids first. Do not list every healthy monitor, only the ones that were part of the story.

Next pull change context from GitHub. Use List Pull Requests filtered to closed pull requests against the main branch and sorted by most recently updated, or Search Issues and Pull Requests with a merged qualifier for the relevant date, to gather everything merged into main since the previous shift began. Line those merges up against incident start times and flag likely culprits. When a merge landed shortly before an incident opened on a related service, name it with the pull request title, its author, and the merge time. Be honest about confidence and say when a correlation is a guess rather than a certainty.

Finally deliver it. Use Slack Bot Look Up User by Email to match the incoming on-call engineer's Better Stack email to their Slack account, then use Send a Message to DM them the brief. Post the same brief to our team reliability channel so the context is not trapped with one person.

Order the brief by what still needs attention: unresolved incidents first, then flapping or repeat-offender monitors that fired more than once in the window, then merged changes worth watching. Keep it short and skimmable, the kind of thing someone reads on a phone before their first coffee. If there is genuinely nothing to escalate, say plainly that it was a quiet shift with nothing outstanding rather than padding the brief to look thorough.

One operational note: Better Stack API tokens are scoped to a single team, so if we run several rotations, set up one run of this workflow per schedule, each pointing at its own channel.

## How to customize

- Retime it to land exactly on your rotation boundary, and run it all seven days if you have weekend shifts
- Point it at a different repository or branch if your team ships from somewhere other than main
- Widen or narrow the lookback window when your shifts are longer or shorter than 24 hours
- Change what counts as worth escalating, for example only incidents over a certain length or monitors that fired more than twice

## FAQ

### What happens when nothing went wrong overnight?

The brief says plainly that it was a quiet shift with nothing outstanding. It will not pad the message with a wall of healthy monitors just to look thorough, which is the fastest way to get people to stop reading it.

### How does it know which person in Slack to message?

It takes the incoming on-call engineer's email from your Better Stack schedule and looks up the matching Slack account. If your team uses different email addresses in the two tools, you can tell the agent how to map them.

### We run more than one on-call rotation. Does that work?

Yes, though a Better Stack access token covers a single team, so the cleanest setup is one copy of this workflow per rotation. Each copy points at its own schedule and its own channel.

### Can it run at a time other than 9am?

Yes. The schedule is the easiest thing to change, and follow-the-sun teams often run a copy at each handoff time rather than just once a morning.

### How reliable is the link it draws between a merge and an incident?

It is a starting point, not a verdict. The agent flags merges that landed shortly before a related incident opened and says when a connection is a guess, so the incoming engineer knows where to look first without being told a conclusion that has not been proven.

Use this prompt in General Input: https://www.generalinput.com/prompts/daily-on-call-handoff-brief-from-better-stack-to-slack