New Relic

New Relic exposes a broad set of object types: APM entities, hosts, browser sessions, mobile applications, synthetic monitors, alert issues, deployment events, and error groups. This integration focuses on two object types that carry reliable per-user attribution: alert issues, which record who acknowledged and who resolved each incident, and deployment events, which record who pushed each change. APM entities, error rates, and Apdex scores were considered but excluded because they are system-level metrics with no owner field — they measure the health of a service, not the contribution of an individual. Four KPIs were retained, selected against three criteria: ability to attribute to a named engineer, resistance to gaming, and balance between leading and lagging indicators.

Incident response: reading on-call performance through paired indicators

Three KPIs cover incident management. They are designed to be read together, because each in isolation invites a different form of distortion.

Responsiveness and resolution speed

Mean Time To Acknowledge measures the average delay between the creation of an alert and the moment an engineer marks it as acknowledged. Mean Time To Resolve measures the average delay between creation and closure. The two indicators are both DORA-adjacent and address different phases of the incident response chain. Mean Time To Acknowledge is a leading indicator of on-call culture: a low value signals that engineers are actively monitoring their alerts and responding before escalation is needed. Mean Time To Resolve is the lagging counterpart, measuring whether the team is able to restore service once the incident is under active management. A wide divergence between the two — fast acknowledgment combined with long resolution — identifies incidents that engineers engage with promptly but cannot resolve without external dependencies or prolonged investigation.

Responsibility for high-severity incidents

Critical Incidents Acknowledged counts the number of critical-priority alerts that a given engineer has acknowledged during the period. It is a lagging indicator of ownership: it identifies who in the team is absorbing the highest-severity on-call burden. This KPI is particularly useful as a complement to Mean Time To Resolve. A high Mean Time To Resolve with a high count of Critical Incidents Acknowledged suggests the engineer is carrying a disproportionate share of the most complex incidents; a low count combined with a favorable Mean Time To Resolve may indicate the engineer is resolving easier incidents while others handle critical alerts. Reading the two indicators together surfaces distribution imbalances in incident responsibility that aggregate team-level metrics systematically conceal.

Mean Time To Resolve also carries a gaming risk: an engineer can close an issue prematurely and allow it to re-trigger, cycling through multiple short resolutions to improve the metric. Critical Incidents Acknowledged counterbalances this risk by focusing on the volume of serious work accepted rather than the speed of closure. An engineer gaming Mean Time To Resolve would need to simultaneously maintain a credible volume of critical incident acknowledgments, which constrains the adversarial strategy.

Deployment frequency: a leading indicator of engineering throughput

Deployment Frequency counts the number of deployments pushed by a given engineer during the period. It is one of the four DORA metrics and serves as a leading indicator of engineering throughput: teams that deploy frequently tend to release smaller, safer changes, which correlates with lower incident rates and faster recovery. At the individual level, Deployment Frequency surfaces contribution patterns that are invisible in ticket-tracking systems — engineers who build and ship, as opposed to those who plan or review.

This KPI carries a moderate gaming risk: a pipeline that tags each micro-commit as a separate deployment can artificially inflate the count without reflecting meaningful delivery. The counterbalance is Mean Time To Resolve: high deployment frequency that generates an elevated incident rate will immediately show as a degraded resolution time. The combination prevents the volume-versus-stability tension from collapsing in either direction — neither artificially slowing deployments to avoid incidents nor pushing changes without monitoring their consequences.

Scope and limits of the integration

New Relic records observable system behavior, not the quality of engineering judgment. Mean Time To Resolve measures how fast an incident is closed, not whether the underlying cause was correctly diagnosed and durably fixed. An incident closed in twenty minutes may reflect a confident rollback or a superficial workaround that defers the problem; the API data does not distinguish between the two. Similarly, Deployment Frequency counts events in the change tracking log without assessing whether the change was well-designed, adequately reviewed, or accompanied by sufficient test coverage.

Attribution depends on two behavioral conditions. First, the deployment pipeline must populate the user field with a valid, consistent email address; freetext entries from CI/CD configurations that use service account names or generic identifiers will fail to match against Human Bridge user records. Second, incident acknowledgment and closure must be performed in New Relic by the engineer who actually responded, rather than by a team lead closing tickets on behalf of others. When these conditions are met, the KPIs provide a reliable per-engineer signal; when they are not, the data degrades silently. The operational quality of on-call practice and deployment tooling configuration is, in this integration, the binding constraint on measurement quality.