SLOs and Bug Priority

SLO impact drives bug priority.

Calculate

Most bug-priority systems are vibes. P0, P1, P2 get assigned based on whoever is loudest in the triage meeting, with a rough sanity check on customer impact and a guess at engineering effort. The result is priority that drifts: yesterday's P1 becomes today's P2 not because the bug changed but because attention shifted. SLO-anchored priority replaces vibes with arithmetic.

How to actually compute SLO impact per bug:

• Per-bug SLO impact estimate.: Each bug gets an estimate of how much SLO budget it consumes per week (or per month, or per however the SLO is windowed). The estimate is a number, not a label. "This bug consumes roughly 4% of the API service's monthly error budget" is precise enough to compare against other bugs.
• Three inputs to the estimate.: Frequency (how many requests hit the bug per unit time), severity per occurrence (does it cause an error, slow response, partial success), and SLO sensitivity (how does the user-experienced failure map to the SLO definition). Multiply them out, get a budget burn rate, compare across bugs.
• Quantified, not categorical.: The output is a percentage of the SLO budget. Every bug has a number. The numbers are comparable across services because SLO budgets are normalized. A 5% budget burn on the search service is comparable to a 5% budget burn on payments, even though the absolute traffic is different.
• Refresh the estimate from real data.: Once the bug is observed in production, the estimate gets calibrated against actual behavior. The bug that "should" consume 2% of budget but is actually consuming 8% has its priority recomputed automatically. The math stays current as the data accumulates.
• Visible on every ticket.: The estimated and actual SLO impact appears on every bug ticket alongside the title and description. This is the data engineers and PMs use to decide what to work on, in the same surface where the work itself is tracked.

The calculation is the layer that makes SLO-driven priority possible. Without it, priority discussions remain about who feels strongest about which bug.

Priority

Once every bug has an SLO impact number, priority follows mechanically. The team works on the bugs that consume the most budget first. Disagreements about priority become disagreements about the impact estimate, which is a much narrower and more productive conversation.

• High SLO impact equals high priority.: A bug consuming 10% of the budget is higher priority than one consuming 1%, regardless of which is more annoying or more visible to the team. The customer experience is what is being measured, and the customer cares about the budget burn, not which bug is more interesting.
• Aligned across teams.: Every team uses the same priority framework. The customer support team's escalations get evaluated against the same SLO-impact yardstick as the engineering backlog. Priority arguments collapse because everyone is referring to the same number.
• Tied to error budget burn.: When the error budget is healthy, the team can absorb low-priority bugs without urgency. When the budget is burning, even normally-low-priority bugs may need to fight for the remaining budget. The framework handles both states without changing the rules.
• Avoids "loudest customer wins.": A single customer complaining loudly about a bug that affects only them gets accurately weighted against a quieter bug affecting thousands of users. The SLO impact reflects total user impact, not the volume of complaints from any one user.
• Survives the next sprint planning.: Priority does not silently slip when the team gets distracted. The SLO impact data is durable and reviewable. A bug that should have been P1 last quarter and got bumped to P3 by attention drift has its SLO data right there to challenge the demotion.

Mechanical priority is not the same as inflexible priority. The team still has judgment calls; the framework just makes the inputs to those calls explicit and comparable.

Avoid

The priority systems that fail are the ones based on subjective categorical labels without grounding. They feel objective because they have numbers (P0 through P5) but the assignment of those numbers is ungrounded.

• Avoid priority by feel.: "This bug feels important" is not a priority signal. It is the team's anxiety about which bug is most likely to embarrass them, which is correlated with SLO impact but only weakly. Priority by feel produces a backlog where the most-fixed bugs are the most-talked-about, not the most-impactful.
• SLO data is objective.: The SLO impact estimate is computed, not declared. Engineers can disagree about it, but the disagreement is grounded in observable data: traffic counts, error rates, latency percentiles. The conversation moves from "I think this is more important" to "the data shows this consumes more budget."
• Data-driven, not data-only.: The framework does not eliminate judgment. It anchors judgment to evidence. The team can override the SLO-implied priority for strategic reasons (a low-impact bug that blocks a major feature, a high-impact bug that has a complete workaround). The override is documented; the default is the data.
• Avoid revisiting priority on every ticket.: Without the framework, every triage meeting relitigates priority for every open bug. With the framework, the SLO impact recomputes automatically and the team only revisits the cases where the data has changed materially. The meeting gets shorter; the decisions get sharper.
• Avoid letting senior engineers veto by reputation.: "Sarah says this bug is P0" is not a system. Sarah might be right, but if she cannot point to the SLO impact data that justifies P0, she is operating on intuition. The framework forces senior intuition to translate into evidence, which is a healthy discipline.

SLO-anchored bug priority is one of the highest-leverage operational habits a team can adopt because it changes how the entire backlog gets prioritized. Nova AI Ops computes per-bug SLO impact estimates from production telemetry, tracks the budget burn each open bug is contributing, and exposes the data on every ticket so priority decisions are anchored to evidence instead of to whoever is loudest.