You measure incidents, but ignore the metrics that matter (and that's why your team isn't improving)

69% of teams measure the number of incidents. Only 12% use custom metrics that actually predict problems. The result: you know when you fail, but not why or how to prevent it.

The data point that should worry you

LeadDev has just published its Engineering Performance Report 2025 with data from 400 engineering leaders. One question shatters the industry's collective self-deception:

"What metrics does your team use to measure systems performance?"

The answers:

• 69%: Number of incidents
• 60%: Incident severity
• 51%: SLA compliance
• 46%: Uptime
• 44%: Operational costs
• 12%: Custom metrics

Translation: 7 out of 10 teams measure how many times the system goes down. Only 1 in 10 measures what actually predicts whether it's about to go down.

If your main dashboard is an incident counter, you're not measuring performance. You're measuring failures.

Why this is a problem (bigger than it looks)

1. Reactive metrics don't prevent problems

Measuring incidents is like measuring car crashes to improve your driving. It tells you that you crashed, not why or how to avoid it.

The vicious cycle:

1. Incident happens → counter goes up
2. Post-mortem → "we need more monitoring"
3. You add more dashboards of... incidents
4. Next incident → repeat

Result: More data about the past, zero ability to prevent the future.

2. You ignore the metrics that do predict (and cost less)

According to the same report, only 39% track "engineering time" (how the team spends time on tasks).

This is critical because:

• A team that spends 60% of its time "firefighting" is going to have incidents
• A team that spends 40% on technical debt is going to reduce incidents
• But if you don't measure time, you don't know where you're spending it

Real example (a client of ours, Series B fintech):
Before: They measured incidents only (5-8/month)
After: They added team-time tracking → They discovered 70% of the time went to "urgent patches" → They cut patches to 30% and increased refactoring to 40% → Incidents dropped to 1-2/month within 2 months.

They didn't need more incident monitoring. They needed to measure where they were spending their time.

3. The uptime paradox

46% of teams measure uptime. Sounds reasonable, right?

The problem: uptime is a result metric, not a cause metric.

Typical scenario:

• Your system has 99.9% uptime (43 min downtime/month)
• You think you're doing fine
• But that 99.9% hides the fact that:
  • 80% of the team is in "firefighter mode"
  • A deploy takes 6h out of fear of breaking things
  • Technical debt grows unchecked

High uptime ≠ a healthy system. It can be an exhausted team propping up a house of cards.

The metrics that DO predict (and nobody measures)

According to the LeadDev Report, these are the least-tracked yet most predictive metrics:

1. Engineering time breakdown (39% measure it)

What to measure:

• % time on new features
• % time on bugs/patches
• % time on technical debt
• % time "firefighting"

Why it matters: If >50% of the time is reactive (bugs + fires), your system is sick even if uptime is 99.9%.

2. MTTD - Mean Time To Detect (23% measure it)

What it is: The time between a problem occurring and you detecting it.

Why it matters: A bug that takes 3 days to detect causes 10x more damage than one detected in 10 minutes.

Benchmark: Good: <30 min MTTD for critical issues | Excellent: <5 min MTTD (proactive monitoring + alerts)

3. Deployment frequency + lead time

Why it matters: Teams that deploy 10x/day have 60% fewer incidents than teams that deploy 1x/week (DORA metrics).

The paradox: More deploys = fewer incidents (because small changes are less risky).

4. Custom metrics (only 12% use them)

What they are: Metrics specific to your domain that predict problems.

Examples:

• E-commerce: "Checkout abandonment rate"
• Fintech: "Failed transaction retry rate"
• SaaS: "API error rate per client"

The invisible metric (that explains all the others): Team cognitive load

There's one metric that almost nobody tracks but that explains why the other metrics fail: the team's cognitive load.

What is cognitive load in development teams?

Definition: The amount of information a developer has to keep in their head to be productive.

The 3 types of cognitive load (according to Team Topologies):

1. Intrinsic load: The inherent complexity of the task
2. Extraneous load: Noise from the environment (badly configured tools, manual deploys)
3. Germane load: The useful learning that sticks

How to measure cognitive load (without complex surveys)

✅ Context switches per day:

• <3 switches/day = manageable load
• 5-7 switches/day = high load (productivity -60%)
• >10 switches/day = collapsed team

How to measure: Track Jira/Linear tasks per developer per day + calendar meetings.

✅ Time to productive (new developer):

• <2 weeks = simple architecture, good documentation
• 4-6 weeks = medium complexity
• >8 weeks = brutal cognitive load

✅ Tool proliferation:

• <5 tools = fine
• >10 tools = brutal extraneous load

The hidden connection: Cognitive load → Incidents

Why teams with high cognitive load have more incidents:

1. An exhausted developer makes mistakes: Cognitive load >80% → 3x more bugs introduced
2. Zero time for prevention: If 70% of the time is firefighting, there's no mental space for refactoring
3. Loss of context: Switching context 7x/day → you forget edge cases, you skip tests

DevEx: The metric that unifies all the others

Developer Experience (DevEx) isn't about "having a nice Slack". It's about measuring friction in the developer's daily work.

The 3 dimensions of DevEx (according to the SPACE framework):

1. Feedback loops: How long does it take a developer to validate a change?
   • Build time: <5 min = excellent, >15 min = high friction
2. Flow state: How many hours of deep work without interruptions?
   • <2h/day = reactive team (brutal cognitive load)
   • 4-6h/day = healthy team
3. Cognitive load: How much unnecessary complexity is the developer carrying?

High cognitive load
  → Exhausted developer
    → More bugs introduced
      → More incidents
        → More firefighting
          → Less time for refactoring
            → Technical debt grows
              → Riskier deploys
                → More cognitive load
                  → [cycle repeats]
          

Framework: Which metrics to track (and in what order)

Level 1: Basic (if you don't have this, start here)

• Uptime / downtime
• Number and severity of incidents
• MTTR (mean time to resolve)

The problem: You only measure failures, not prevention.

Level 2: Intermediate (this is where you really improve)

• MTTD (mean time to detect)
• Engineering time breakdown
• Deployment frequency + lead time
• Operational costs per service

The benefit: You start seeing patterns BEFORE incidents.

Level 3: Advanced (this is where you compete with top performers)

• Custom metrics for your domain
• Cost per feature
• % code coverage + mutation testing
• Change failure rate
• Context switches per developer (cognitive load)
• Feedback loop time (DevEx)
• Flow state hours (deep work time)

The benefit: You predict problems weeks in advance and measure the health of the team, not just the system.

Real case: From firefighting to 0 incidents in 8 weeks

Client: Series B healthtech scaleup, 15 developers
Problem: 6-8 incidents/month, exhausted team

Phase 1: Diagnosis (Weeks 1-2)

• We implemented engineering time tracking
• The finding: 65% of time on hotfixes and patches
• Root cause: They weren't measuring MTTD or deployment frequency

Phase 2: Predictive metrics (Weeks 3-4)

• We added MTTD tracking: 4 hours on average (bad)
• We added deployment frequency: 2x/week (low)
• We added a custom metric: "API timeout rate per endpoint"

Phase 3: Action (Weeks 5-8)

• They prioritized cutting MTTD to <30 min (better alerting)
• They increased deploys to 2x/day (CI/CD refactor)
• They monitored API timeouts → they caught 3 problematic endpoints before incidents

Results (2 months later):
• Incidents: 6-8/month → 0-1/month (-87%)
• MTTD: 4h → 15 min (-93%)
• Time on hotfixes: 65% → 20% (-70%)
• Context switches: 8/day → 4/day (-50%)
• Flow state: 1.5h/day → 5h/day (+233%)

Investment: 40h of team time + €200/month tooling
ROI: ~120h/month saved = €12k/month

"We're finally working on features, not fires"

Key insight: Reducing context switches was the change that made everything else possible. With more flow state, they detected problems earlier, wrote better code, and reduced bugs.

Immediate action: What to do this week

Monday (1h): Audit your current metrics

Honest question: What % of your metrics are reactive (incidents) vs. predictive (MTTD, time breakdown, custom)?

If >70% are reactive, you're in firefighter mode.

Tuesday (2h): Add 1 predictive metric

Pick one:

• Engineering time breakdown (easiest to start with)
• MTTD (most impact if you have frequent incidents)
• Deployment frequency (most impact if deploys are painful)

Wednesday-Friday (3h): First analysis

• Track the metric for 1 week
• Analyze the first data
• Identify 1 quick win

Conclusion: Stop counting failures, start predicting successes

The problem with measuring only incidents:

• You know you failed
• You don't know why
• You can't prevent the next one

The solution:

• Measure team time (to know whether you're in reactive mode)
• Measure MTTD (to detect problems before they escalate)
• Measure custom metrics for your domain (to predict problems days in advance)
• Measure cognitive load and DevEx (to understand the real health of your team)

The mindset shift: From "how many incidents did we have?" to "how many incidents did we prevent?"

Written by

Jordi García

Tech Lead at onext

Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.

LinkedIn →