Key takeaways
New Relic reports that 44% of teams take 30+ minutes to detect high-business-impact incidents, and 60% take 30+ minutes to resolve them. For tracking incidents, that delay means paid media and reporting can run on degraded signals for too long.
MTTD means Mean Time To Detect: the average time it takes your team to notice a tracking incident after it starts. MTTR means Mean Time To Resolve: the average time it takes to fully fix that incident once it has been detected.
- Start by improving MTTD first, because faster detection shrinks incident cost even before total incident count drops.
- Define severity with business impact, not technical preference, so teams fix budget-risk incidents first.
- Route alerts by owner and monitor domain to reduce handoffs and escalation confusion.
- Run weekly incident reviews to remove repeat failure patterns and reduce future MTTR.
Why do MTTD and MTTR matter more than incident count?
Gartner estimates poor data quality costs organizations $12.9M per year on average. That is why MTTD and MTTR are practical operating KPIs: they measure how long the business is exposed to bad data, not just how many incidents occurred.
Incident count can stay flat while financial impact drops if teams detect and resolve faster. In paid media workflows, a 2-hour high-severity issue is usually far cheaper than a 2-day medium issue nobody notices quickly.
Related links
What does a business-first severity model look like?
A useful severity model starts with business impact, not just technical symptoms. For measurement teams, severity should reflect spend at risk, attribution distortion, and decision confidence impact.
A practical model is: Sev 1 for conversion-signal failures affecting optimization decisions, Sev 2 for partial signal degradation with measurable reporting impact, and Sev 3 for low-risk discrepancies that can wait for normal backlog handling.
When we support teams through incident triage, the biggest delay often happens before troubleshooting starts: ownership and severity are unclear. A written severity matrix removes that friction and speeds first action.
- Sev 1 example: purchase event value missing across high-spend channels.
- Sev 2 example: parameter drift in one template affecting segmented reporting.
- Sev 3 example: naming inconsistency with limited downstream impact.
Related links
How should alert routing be designed to reduce handoffs?
Alert routing should follow fix ownership, not org chart hierarchy. If alerts reach teams that cannot act, MTTD can look fine while MTTR stays high due to handoff delays.
Route availability and dispatch issues to engineering, payload integrity issues to analytics or martech, and destination-specific failures to channel owners. Use one accountable incident owner from open to close.
The highest-value alert is not the noisiest one. It is the one that arrives in the right channel with clear ownership and a ready first action.
Related links
What is the 15-30-60 minute incident response playbook?
In the first 15 minutes, teams should validate scope and severity. Confirm whether the issue affects all traffic or specific segments, and classify risk level before deep debugging starts.
By 30 minutes, assign one owner, decide rollback versus hotfix, and communicate status to stakeholders impacted by reporting or bidding decisions.
Within 60 minutes, contain impact, document root-cause direction, and define follow-up checks. This converts incident response from ad hoc firefighting into a repeatable operating loop.
- 15 minutes: scope + severity.
- 30 minutes: owner + mitigation path.
- 60 minutes: containment + communication + follow-up checks.
How do teams reduce repeat incidents month over month?
Weekly incident reviews are where MTTD and MTTR trend lines improve. Review not only what failed, but where detection lag and ownership friction appeared.
Track recurring failure classes, false-positive rates, and top escalation bottlenecks. Then tune thresholds, ownership mappings, and response playbooks based on what the incidents actually revealed.
Frequently asked questions
Should we prioritize MTTD or MTTR first?
Start with MTTD. New Relic data shows many teams still need 30+ minutes to detect major incidents, so reducing detection lag is usually the fastest way to cut business impact windows.
How many severity levels should we use?
Three is enough for most monitoring teams: critical, high, and normal. More levels often add process overhead without improving prioritization quality.
How often should routing rules be reviewed?
Monthly is a strong baseline, plus after major releases or org changes. Routing drift causes avoidable handoffs and slower MTTR.
Can small teams run this model?
Yes. Start with one monitor domain, one owner model, and one triage rhythm. Expand once your first workflow is stable.
Bottom line: faster detection plus cleaner ownership wins
Reducing MTTD and MTTR is not a tooling-only project. It is an operating model decision that combines severity definitions, alert routing, ownership, and consistent review cadence.
If your team wants fewer budget-risk surprises, prioritize speed-to-detect, assign one accountable owner per incident, and run weekly improvement loops. That is how monitoring becomes a repeatable performance advantage.