Error budget review board for your weekly reliability meeting

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.