Mean Time to Detect: How Quickly Will You Know an Integration Failed?

What is MTTD?

Mean time to detect is the average time between the start of an integration failure and the first detection event.

MTTD = Average(first detection time − failure-start time)

For a single incident, that would be:

Detection time = First detection time − failure-start time

Choose the event that starts the clock for each failure type. For scheduled work, a missed execution may be the failure-start event even when no execution record exists. In that case, define the expected execution time or interval before measuring the delay.

Then, define the detection event just as carefully. These are different events. Do not treat them as interchangeable. Use one definition consistently for the MTTD question you are trying to answer.

Time to actionable alert

If you want to evaluate alerting specifically, track time to actionable alert as a related measure:

Time to actionable alert = First actionable alert delivered − failure-start time

Track acknowledgment separately when you need to measure how long it takes someone to confirm they've seen an issue. Acknowledgment measures human response after detection; it is not the same as detection.

Why MTTD matters

A failure that is eventually repaired can still create data issues.

A high MTTD may indicate that:

• A missed scheduled execution did not alert.
• An alert was not configured for the failure mode.
• The alert reached the wrong team or channel.
• Logs lacked enough context to identify the affected customer or integration.
• A portfolio dashboard hid a problem in one integration.
• The first detection came from a customer report.

MTTD does not measure recovery or restoration time. In this series, mean time to recovery, or MTTR, means the average time from detection to restoration of the integration's defined operational state. Because different teams use MTTR to mean recovery, repair, or resolution, define the start and end events to ensure a consistent measurement.

How to measure MTTD

1. Define the failure-start event

Choose the event that starts the clock the various failure types.

Document whether that is:

• The first execution that fails
• A breach of a defined reliability threshold
• A missed expected execution

For scheduled work, a missed execution is often be the failure-start event. But, be careful not to infer a missed execution from a gap in the dashboard data. Define the expected schedule or interval first.

2. Define detection

Document what "detected" means:

• Is it an automated signal?
• Is it an actionable alert?
• Did the owning team become aware of the issue?
• Did a customer report the issue?

Choose the definition that matches your question. Use alert delivery to evaluate the monitoring system; use team awareness to evaluate operational response. Keep those separate rather than blending them into a single number.

3. Record the timestamps

For each incident, capture as many of these as your systems support:

• Failure-start
• First detection
• First actionable alert
• Human acknowledgment
• Recovery
• Data reconciliation, if historical records need repair

MTTD uses the failure-start and detection timestamps directly. The others help explain where the response slows down.

4. Segment and summarize the result

Calculate MTTD per incident, then segment it by:

• Failure type – missed execution, connection or authentication, execution, dependency, or data issue
• Integration, customer, and severity
• Detection source – proactive alert, internal report, or customer report
• Time period

Report the mean, median, and any useful percentiles. The mean supports comparison, the median shows the typical incident, and upper percentiles reveal the longest customer exposure.

What Prismatic provides

Prismatic can provide operational evidence that supports MTTD measurement, including:

• Configured alert monitors such as Execution Failed, Execution Overdue, Execution Duration Matched or Exceeded, Connection Threw an Exception, and Log Level Matched or Exceeded.
• Alert-delivery information when monitors and notification destinations are configured.
• Execution history and logs for failure context.
• Instance-level context for investigating the affected integration and customer.

Execution Overdue is intended for an applicable expected-execution interval. When configured for a scheduled or otherwise measurable flow, it can help identify an expected execution that did not occur within that interval. It is not a universal detector for every webhook or event-driven flow.

Alert delivery is a useful proxy for detection, but your team still needs to define:

• The failure-start event
• The detection event
• Inclusion and exclusion rules
• Reporting segments
• The target for each integration or workflow

Prismatic provides execution data and operational tooling. Your team defines the metric and how it should operate in your environment.

Start with a baseline

Unfortunately, there is no universal MTTD target. Establish a baseline, then set targets according to dependency risk, customer impact, and SLAs.

The important first step is to measure the same events consistently. Once you know where detection slows down, you can improve monitoring and everything else that follows.