Sentry

Sentry exposes several object types: issues (error groups), events, releases, projects, teams, and members. This integration focuses on two of them — issues and releases — which together cover the two axes of production reliability management: the response to existing errors and the quality of new code shipped. Other objects, such as events or teams, are valuable for operational context but do not produce indicators that can be attributed reliably to individual contributors. Five KPIs were retained, selected against three criteria: ability to attribute to a single owner by email, resistance to gaming, and balance between leading and lagging indicators.

Incident response: reading the resolution cycle

Three KPIs track how an engineer manages the issues assigned to them. They are deliberately designed to constrain each other, preventing any single indicator from being optimized in isolation.

Volume and speed

Issues Resolved counts the number of error groups that a developer has brought to resolved status during the period, excluding resolutions by the ignore button, which suppress visibility without fixing the underlying cause. Mean Time to Resolution measures the average elapsed time between the moment an issue first appears in production and the moment it is resolved. Read in isolation, each indicator is incomplete: a high resolved count achieved through rapid closures may indicate superficial fixes, while a low mean resolution time on a small resolved volume may simply reflect that only easy issues were selected. Read together, they reveal whether the engineer is processing a meaningful volume at a sustainable speed, or concentrating effort on either quantity or ease.

Quality counterbalance

Regression Rate measures the proportion of issues that were marked resolved and subsequently re-opened as regressed — meaning the error recurred in production after the fix was deployed. This indicator is the primary quality counterbalance to Issues Resolved. It is difficult to game: a high regression rate is a direct signal that closures were premature, regardless of how fast they were recorded. The pair of Issues Resolved and Regression Rate creates a self-correcting system: pressure to increase resolved volume that results in inadequate fixes will surface immediately in the regression metric. A minimum sample of resolved issues is required before the ratio is statistically meaningful, which limits its usefulness for engineers handling fewer than ten issues per period.

Backlog pressure

Critical Open Issues counts the unresolved issues of fatal level or critical priority that are currently assigned to the engineer. Unlike the other indicators in this block, it is a leading indicator: it reflects the current state of the backlog before any action has been taken. Its management value is directional rather than retrospective — an increase signals accumulating pressure that will likely drive Mean Time to Resolution upward in subsequent periods unless cleared. This KPI is most useful as a daily operational signal and as an input to workload conversations, rather than as a long-horizon performance measure.

Release quality: attributing new errors to their source

New Issues Introduced measures the total number of new error groups that appeared in production following releases where the engineer is listed as an author. This indicator connects the deployment event to its downstream effect: rather than tracking only whether bugs were fixed, it tracks whether new bugs were introduced. The combination of Issues Resolved and New Issues Introduced creates a net reliability view — a developer who resolves ten issues and introduces three is producing a different outcome from one who resolves ten and introduces none, and the difference is managerially significant.

This indicator carries an attribution caveat that must be made explicit. In teams that use squash merges or automated deployment pipelines, the commit author recorded on a release may be a CI bot or a release manager rather than the engineer who wrote the code. In such configurations, New Issues Introduced will either be blank for most engineers or concentrated on a single automation account, making it analytically unreliable at the individual level. Teams using standard branch-based workflows with individual commit authorship will find the indicator meaningful; teams with automated pipelines should treat it as a team-level signal rather than a per-engineer measure.

Scope and limits of the integration

Sentry records error occurrence, assignment, and resolution status, but does not measure the quality of the fix implemented. An issue marked resolved may correspond to a precise root-cause analysis and a permanent solution, or to a workaround that temporarily suppresses the error. The Regression Rate indicator partially compensates for this by surfacing premature closures after the fact, but it does so with a delay and only when the error recurs under the same pattern.

A structural limitation of this integration is the assignment model. Many issues in Sentry are unassigned, particularly in teams without a formal triage process, or are assigned to a team rather than an individual. Unassigned and team-assigned issues are excluded from all per-user KPI calculations by design, which means the integration only captures a fraction of the total error volume in environments where assignment discipline is weak. The reliability of these KPIs therefore depends directly on the team's practice of assigning every issue to a named individual: teams that triage and assign consistently will see accurate individual indicators; teams that leave issues unassigned will see systematically underreported metrics that do not reflect actual workload.