Datadog

Datadog exposes a broad set of object types: incidents, monitors, SLOs, metrics timeseries, logs, traces, events, hosts, and dashboards. This integration focuses on two objects — incidents and SLOs — which together provide the most direct and attributable performance signals for engineering and reliability teams. Metrics timeseries, logs, and traces were set aside because their aggregation at the individual level does not produce indicators that are causally linked to a specific engineer's contribution. Seven KPIs were retained, selected against three criteria: ability to attribute to an owner resolvable by email, resistance to gaming, and balance between leading and lagging indicators.

Incident response: reading speed and severity together

Five KPIs are derived from incidents, all attributed to the incident commander — the engineer who owns the remediation. They cover three distinct dimensions of on-call performance: response speed, severity exposure, and business impact.

Response speed: MTTA and MTTR

Mean Time to Acknowledge measures how quickly the on-call engineer picks up an incident after it is triggered. Mean Time to Resolve measures how long the full resolution cycle takes. These two indicators do not measure the same thing, and conflating them is a common diagnostic error. A low MTTA alongside a high MTTR reveals that incidents are acknowledged promptly but remediation is slow — often a sign of complex, insufficiently documented systems or missing runbooks. The reverse pattern — high MTTA, low MTTR — suggests that the team is slow to detect or claim ownership but resolves efficiently once engaged, pointing to gaps in alerting routing or on-call assignment. Reading MTTA as the leading indicator and MTTR as the lagging outcome surfaces these structural tensions, which neither indicator surfaces alone.

Severity and business impact

SEV-1 Incidents counts the number of highest-severity incidents assigned to a commander. Customer Impact Duration accumulates the total minutes of customer-facing disruption across those incidents. These two indicators are in a relationship of calibration: SEV-1 Incidents reveals the frequency of critical events, while Customer Impact Duration reveals their cost. A high SEV-1 count paired with a low Customer Impact Duration indicates that critical incidents are being contained quickly; the same SEV-1 count paired with a high Customer Impact Duration indicates that remediation is slow or scope is expanding. The ratio between these two indicators is more informative than either value taken in isolation. MTTR serves as the mechanistic explanation: when Customer Impact Duration is disproportionate relative to SEV-1 count, the MTTR for that commander's incidents is the variable to investigate.

On-call load: Active Incidents as a planning signal

Active Incidents counts the number of incidents currently in an active or stable state attributed to an engineer. It is the only indicator in this block that measures current state rather than past outcomes, making it a leading indicator of workload pressure rather than historical performance. An uneven distribution of Active Incidents across engineers during a given period indicates that on-call burden is not shared equally, which predicts degradation in MTTA for overloaded engineers. This KPI does not measure individual performance in isolation; it is a team-level planning input that informs rotation design and capacity allocation.

Reliability contracts: SLO compliance and breach

SLO Compliance Rate measures the average ratio of time a service meets its defined reliability target, across all SLOs owned by an engineer. SLO Breaches counts the number of SLOs currently in a breached state. These two indicators serve different management functions and should not be read as substitutes.

SLO Compliance Rate is a continuous indicator: it captures the degree to which services hover near or above their targets over a reporting window. A compliance rate of 99.85% on a 99.9% SLO target indicates near-miss but not breach, and the trend matters as much as the point-in-time value. SLO Breaches is a binary alarm: it counts the number of SLOs that have crossed the threshold, regardless of how far. Together, these indicators produce a layered picture of reliability health. A high compliance rate combined with a non-zero breach count signals that most SLOs are in good shape but a subset has failed entirely, which would be invisible from the aggregate compliance figure alone. This pairing neutralizes the gaming risk inherent in compliance rate averaging, where a large number of high-performing SLOs can mask a small number of critically breached ones.

Scope and limits of the integration

Datadog captures incident lifecycle events and SLO compliance data, but does not measure the quality of the work performed during an incident. An engineer who resolves incidents quickly may do so by applying partial fixes that produce recurrence; the API does not distinguish a durable resolution from a temporary one. Post-incident analysis, runbook improvements, and root cause documentation — the work that improves reliability systemically — leave no structured trace in the Datadog API and are therefore absent from these KPIs.

The attribution model also carries a structural limitation. The incident commander is the owner field used throughout this integration, but the commander is assigned after an incident is declared, not based on who caused or who is most responsible for the system failure. In large engineering teams, commander rotation means these KPIs reflect on-call exposure as much as individual capability. Additionally, SLO ownership defaults to the SLO creator, which may not match the current service owner if teams or responsibilities have evolved since the SLO was defined. The reliability of these KPIs depends directly on the discipline with which the team assigns incident commanders, declares customer impact, and maintains accurate SLO ownership.