Mean time to detect measures how long it takes your team to discover a bug after it's introduced. A bug committed on Monday and caught on Wednesday has an MTTD of 2 days. A bug committed on Monday and reported by a user on Friday has an MTTD of 4 days and a much higher cost of poor quality.
What is MTTD? It's average time to detect across all defects in a given period. Lower is better. The mttd definition in QA is straightforward: MTTD = total detection time across all bugs / number of bugs detected.
For mobile teams, MTTD (also called mean time to identify in some frameworks) matters more than for web teams because you can't hotfix. A bug that takes 3 days to detect and 2 days to fix still needs 1-3 days for app store review. That's a week of exposure. Quality engineering teams track MTTD to catch bugs faster and ship fixes before users notice. how to reduce your time to detect through better testing, higher coverage, and fewer flaky tests.
What is MTTD formula?
The mean time to detect formula:
MTTD = Total time spent detecting defects / Total number of defects detected
Where "time spent detecting" is elapsed time from when bug was introduced (code committed) to when it was identified (test failure, crash report, user complaint).
A mean time to detection mttd example: your team detects 20 bugs in a sprint. 10 were caught by CI tests within 1 hour. 5 were caught by nightly regression within 24 hours. 3 were caught by QA during manual testing within 72 hours. 2 were reported by users within 168 hours (1 week).
MTTD = (10×1 + 5×24 + 3×72 + 2×168) / 20 = (10 + 120 + 216 + 336) / 20 = 682 / 20 = 34.1 hours
That single number tells you how fast your detection system works. The 2 user-reported bugs skew average. Without them, MTTD drops to 19.2 hours. Those escaped defects are what you need to eliminate.
How does MTTD compare to MTTR and other metrics?
MTTD is one of four incident timing metrics. What is mttr? Mean time to repair. Together they measure full bug lifecycle.
The mttr definition is time from when a bug is detected to when fix reaches users. The mttr meaning for mobile teams includes app store review time, which web teams don't have. Mean time to resolution on mobile is always longer than on web because of that review step.
MTTD + MTTR = total user exposure time. If MTTD is 48 hours and MTTR is 72 hours (including app store review), users are exposed to bug for 120 hours. Reducing either metric reduces exposure.
The mttd meaning for QA teams: it measures your detection effectiveness. The definition mttr for engineering teams: it measures your fix velocity. Both matter. But MTTD is one QA owns directly.
What are MTTD benchmarks for mobile teams?
There are no industry-standard MTTD benchmarks for mobile QA, but here's a practical framework based on bug detection source:
The goal is to shift bug detection upward in this table. Every bug caught by CI instead of production reduces MTTD by days and reduces COPQ by orders of magnitude.
How do you reduce MTTD on a mobile team?
Five actions that reduce mean time to detect on mobile:
Run regression on every merge, not nightly. If your E2E suite runs nightly, a bug committed at 9 AM waits until midnight to get detected (15 hours). If it runs on every merge, detection happens within hour. This single change cuts MTTD for regression-catchable bugs from 12-24 hours to under 2 hours.
Increase CI test coverage of high-risk flows. A flow with no automated test has an MTTD measured in days (until manual QA or a user finds it). A flow with automated CI tests has an MTTD measured in minutes. Prioritize coverage by risk.
Eliminate flaky tests. A flaky test that fails intermittently trains your team to ignore test failures. When a real bug triggers a failure, it gets dismissed as "probably flaky." Flaky tests increase MTTD because they delay acknowledgment. Fix root causes or use tools like Drizz that eliminate selector-based flakiness.
Set up production monitoring alerts. For bugs that escape testing, Crashlytics or Sentry should alert within minutes, not days. Configure alerts for crash-free rate drops below 99.5%, new crash clusters, and ANR rate spikes. This reduces production MTTD from "whenever a user complains" to "within 15 minutes of first crash."
Track MTTD by detection source. Measure what percentage of bugs come from CI, nightly, manual QA, and production. If 20%+ of bugs are user-reported, your automated detection has gaps. This is security mean time to detect principle applied to QA: your monitoring needs to catch threats before users do.
How does MTTD connect to COPQ?
Every hour of MTTD adds cost. Here's math for a mobile app with 100,000 daily active users:
- Bug introduced at Monday 10 AM
- Caught by CI tests at Monday 10:30 AM → 0.5 hours MTTD → fix before anyone notices → COPQ: $0
- Caught by nightly regression at Tuesday 1 AM → 15 hours MTTD → fix before release → COPQ: $200 (engineer time)
- Caught by manual QA at Wednesday → 48 hours MTTD → delays release by 1 day → COPQ: $2,000
- Reported by user on Friday → 96 hours MTTD → hotfix + app store review → COPQ: $15,000+
The same bug costs $0 or $15,000 depending on when it's detected. That's why MTTD is metric quality engineering teams optimize first.
What does an MTTD improvement look like?
A fintech app team measured their MTTD over two quarters:
Q1 baseline: MTTD = 52 hours average
- 35% of bugs caught by CI (MTTD: 1 hour)
- 25% caught by nightly regression (MTTD: 18 hours)
- 20% caught by manual QA (MTTD: 72 hours)
- 20% reported by users (MTTD: 168 hours)
They made three changes: moved regression from nightly to per-merge, added 30 new E2E tests for high-risk flows using Drizz (plain English, Vision AI, real devices), and configured Crashlytics alerts for crash-free rate drops.
Q2 result: MTTD = 11 hours average
- 50% caught by CI (MTTD: 1 hour)
- 35% caught by per-merge regression (MTTD: 2 hours)
- 10% caught by manual QA (MTTD: 48 hours)
- 5% reported by users (MTTD: 72 hours, with Crashlytics alerting within 15 minutes)
MTTD dropped 79% (52 → 11 hours). User-reported bugs dropped from 20% to 5%. The escaped defect rate went from 1 in 5 bugs to 1 in 20 bugs.
FAQs
What is mean time to detect?
Mean time to detect (MTTD) is average time from when a bug is introduced to when it's discovered. The mttd definition: MTTD = total detection time across all bugs / number of bugs. Lower MTTD means your team catches bugs faster. For mobile teams, MTTD includes app store review delay in exposure calculation.
What is difference between MTTD and MTTR?
MTTD measures time from bug introduction to discovery. MTTR (mean time to repair) measures time from discovery to fix deployed. MTTD is what QA owns. MTTR is what engineering owns. Together they equal total user exposure time. The meaning of mttr for mobile includes app store review time.
What is MTTR?
MTTR means mean time to repair (or resolve). The mttr definition is average time from when a defect is detected to when fix reaches users. What is mttr in mobile? It's detection to fix to app store approval to user update. Definition of mttr for mobile teams is always longer than for web because of app review step.
How do you calculate MTTD?
Sum detection times for all bugs in a period and divide by number of bugs. If 10 bugs took 1 hour to detect and 5 bugs took 24 hours, MTTD = (10×1 + 5×24) / 15 = 130/15 = 8.7 hours. Track MTTD monthly and break it down by detection source (CI, regression, manual QA, production).
What is a good MTTD for a mobile team?
A good MTTD target for mobile teams is under 12 hours. Top teams achieve under 4 hours by catching 80%+ of bugs in CI and per-merge regression. The key benchmark: less than 5% of bugs should be user-reported. If more than 20% of bugs come from production, your automated detection has gaps.
What is MTTD in cybersecurity?
MTTD in mttd cyber security measures how long before a security team detects a threat. The mean time to detect cybersecurity average is 212 days according to IBM. Security mean time to detect principles apply to QA too: automated monitoring catches threats faster than waiting for user reports.
