What Is a KPI?
A Key Performance Indicator (KPI) is a measurable value that tells you whether a system — a business, a team, a service — is healthy. Think of KPIs like the vital signs a doctor checks during a routine physical: heart rate, blood pressure, temperature. You don't act on them unless something is abnormal. Their job is to confirm that things are working as expected, or to raise an alarm when they aren't.
KPIs have four defining characteristics:
- They measure steady state. A KPI tracks something you want to maintain, not something you want to change. "API latency below 200ms" is a KPI. You don't wake up every morning trying to improve it — you wake up and check that it hasn't degraded.
- They have thresholds, not targets. A KPI has a red/yellow/green zone. You react when it crosses a threshold. You don't "achieve" a KPI — you sustain it.
- They are lagging indicators. KPIs typically tell you what already happened. Revenue last quarter. Uptime last month. Mean Time to Recovery (MTTR) over the past 90 days.
- They are few. If everything is a KPI, nothing is. A team should track 3-7 KPIs, not 40.
KPIs in DevOps and Platform Engineering
Here are concrete KPI examples relevant to infrastructure and platform teams:
| KPI | What It Measures | Healthy Threshold |
|---|---|---|
| Service Availability | Percentage of time the service is operational | ≥ 99.9% (three nines) |
| Deployment Frequency | How often code reaches production | ≥ 1 per day per service |
| Change Failure Rate | Percentage of deployments causing incidents | < 15% |
| Mean Time to Recovery (MTTR) | Average time from incident detection to resolution | < 1 hour |
| P95 API Latency | 95th percentile response time | < 300ms |
| Infrastructure Cost per Request | Cloud spend normalized by traffic | Stable or declining |
The first four metrics in this table — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and MTTR — are the DORA metrics, named after the DevOps Research and Assessment team at Google. They are the industry-standard KPIs for measuring software delivery performance and are backed by years of research across thousands of organizations. Elite performers on all four DORA metrics consistently outperform their peers on commercial outcomes.
A KPI dashboard built around thresholds, not raw numbers, is what makes this actionable day to day: availability green above 99.9%, yellow between 99.5% and 99.9%, red below that; deployment frequency green at daily or better, yellow if it slips, red if it stalls; MTTR green under an hour, yellow under two, red beyond that. The point isn't the exact cutoffs — it's that everyone glancing at the dashboard can tell at a glance whether something needs attention, without having to interpret a raw number every time.
The Anti-Pattern: KPI Theater
The most dangerous failure mode with KPIs is measuring what's easy instead of what matters. Lines of code written, number of pull requests merged, number of tickets closed — these are activity metrics, not outcome metrics. They incentivize busywork. A senior engineer who deletes 5,000 lines of dead code and simplifies the architecture creates enormous value but looks "unproductive" by activity metrics.
The second failure mode is too many KPIs. When a team tracks 30 metrics, none of them get attention. The cognitive load overwhelms the signal. Ruthlessly prune. If a KPI hasn't triggered an action in six months, question whether it belongs on the dashboard.
A third failure mode is Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. If engineers know that "deployment frequency" is a KPI, they may split large changes into trivial micro-deployments to inflate the count — without any improvement in actual delivery capability. The antidote is to track clusters of related metrics so that gaming one metric causes another to degrade visibly.
Key Point: KPIs are guardrails, not goals. They tell you when something is broken. They do not tell you where to go. If your team's entire planning process consists of "keep the KPIs green," you are maintaining the status quo — which is fine until the status quo becomes obsolete.