# Error budget review board for your weekly reliability meeting

> Put every service reliability target on one screen, worst first, and decide together whether to keep shipping or slow down.

- Workflow type: app
- Services: Datadog, Slack
- Categories: Engineering, Operations
- Published: 2026-08-17

## What it does

- Lists every reliability target you track in Datadog on one board, sorted so the services closest to breaking their promise sit at the top.
- Shows how much room for failure each service has left, how fast it is being used up, and whether the last 7, 30 and 90 days are getting better or worse.
- Opens a detail view where you can log a planned maintenance window or a false alarm so it does not count against the service, or change a target that was set wrong.
- Ends the meeting with one button that posts a plain language recap to your engineering Slack channel.

## What you'll need

- A Datadog account with service level objectives already set up, and permission to view and edit them
- A Slack workspace and the channel where your team wants the weekly recap
- A recurring reliability meeting with engineering and product in the room

## Prompt

I want an app we put on the screen during our weekly reliability meeting, where engineering managers and product stakeholders sit together and decide whether we can keep shipping or need to slow down. Non engineers are in the room, so the whole surface should read in plain language and spell out what the numbers mean instead of assuming everyone speaks fluent SRE.

The main board lists every service level objective in Datadog using Get all SLOs, and switches to Search for SLOs when I type a tag into the filter box at the top so each team can look at just its own services. Each SLO gets one card or row showing its name, the target it promised (for example 99.9 percent), the attainment it is actually running at, how much of its error budget is left as a percentage, and its current burn rate. Sort the board by least error budget remaining first, so the services at risk sit at the top and we work down the list in that order.

Each row also shows a 7 day, 30 day and 90 day trend pulled from Get an SLO's history, with a direction indicator so we can see at a glance whether a service is recovering or degrading. Use clear color banding for healthy, at risk and breached, and put a short explanation next to the numbers in ordinary words, something like "18 percent of this month's error budget is left, and at the current rate it runs out in about 5 days".

Clicking a row opens a detail view for that SLO. It shows the full history over 7, 30 and 90 days, the configuration behind the objective from Get an SLO's details (what it measures, the target, the time window it is judged over), and every adjustment already applied to it from Get Corrections For an SLO, listed with its reason, its description and the period it covered.

Two actions live in the detail view. The first applies a correction with Create an SLO correction, for a planned maintenance window or a false alarm, so that period does not consume the budget. The form asks for a category or reason, a description and a start and end time, and it always applies to the SLO I am looking at by its id (that operation requires exactly one of an SLO id or an SLO query, so always send the id). The second edits the objective itself with Update an SLO when the target is genuinely wrong. Show the current target, let me change it, and put a confirmation step in front of it, because changing a target changes how the service is judged from then on.

Give the meeting somewhere to capture the outcome as we go: a short note against any SLO we discuss, plus one decision for the week (keep shipping, slow down, or something in between). Save these with the app so last week's notes and decision are visible when we open it again.

At the end of the meeting, one button posts a plain language summary of the week to our engineering channel using Slack Send a Message. The recap should name which SLOs are breached, which are trending down over the last 30 days, what we corrected during the meeting and why (pull the week's adjustments with Get all SLO corrections so nothing applied outside the meeting is missed), the notes we took, and the decision the room reached. Write it so anyone in the company can follow it without knowing what a burn rate is, and let me preview and edit the text before it sends.

Keep jargon out of the interface. Where a term is unavoidable, explain it inline: an error budget is how much unreliability a service is allowed before it breaks its promise, and burn rate is how fast that allowance is being spent. History is fetched per SLO so the board can take a moment to fill in, so load the rows progressively rather than blocking on everything, and let me refresh without losing the SLO I have open.

## How to customize

- Filter the board by tag so each team reviews only its own services
- Move where the healthy, at risk and breached color bands start
- Choose which Slack channel gets the recap and what the recap covers

## FAQ

### What is an error budget?

Every service promises a level of reliability, for example that it works 99.9 percent of the time. The error budget is the small amount of failure that promise allows before it is broken. Spending it slowly is normal. Spending it fast is the signal that a team should stop shipping new work and fix stability instead.

### Do I need to be an engineer to read this board?

No. That is the point of it. Every number comes with a sentence in ordinary language explaining what it means, so product managers and other stakeholders in the room can follow the discussion without a reliability background.

### What happens when we mark something as a planned maintenance window?

The app records an adjustment against that service in Datadog covering the time period you choose, with the reason you type in. The downtime stays visible in your history but stops counting against that service's reliability promise, which is the same thing you would do by hand in Datadog.

### Can we look at only our own team's services?

Yes. Type a tag into the filter at the top of the board and it narrows to the services carrying that tag, so each team can run its own review off the same app.

### Does it post to Slack on its own?

No. Nothing is sent until somebody clicks the button at the end of the meeting, so you can review the recap before the rest of the company reads it.

Use this prompt in General Input: https://www.generalinput.com/prompts/error-budget-review-board-for-your-weekly-reliability-meeting