Mean Time to Integration Recovery

Post 3 of the Integration Health series

Key takeaways

Mean time to recovery runs from detection to restoration. MTTR is the average of recovery time minus detection time. It excludes time to acknowledge, diagnose, or correct/reconcile the data.
Detection and recovery need precise definitions. Detection can be an automated signal, alert delivery, team awareness, or a customer report, and recovery can mean new executions succeed again in the integration’s normal operating state.
Recovery is not data reconciliation. Updating expired credentials enables new executions but doesn't repair records. Track time to data reconciliation separately.
High recovery times reveal process gaps. Recovery can take longer because of a slow or incomplete diagnosis, unclear ownership, missing runbooks, restricted log access, and error categories without a response procedure.
Median and p90 beat the mean alone. Report them as primary views and keep the mean for comparison.

An integration can fail at 9:00 AM, trigger an alert at 9:05, and still leave a customer wondering where the data is several hours later.

Mean time to recovery, or MTTR, measures how long it takes to restore normal integration operation after a failure is detected. It is not the same as time to acknowledge, diagnose, or correct the data.

Who needs this

If your team gets alerts quickly but customers can sit with inaccurate data for hours while someone digs through logs, ownership questions, or missing runbooks, this is for you. Tracking MTTR is essential for any engineering or DevOps team that wants to turn detection into reliable, repeatable recovery instead of extended firefighting sessions.

Watch the video

Watch the overview, or keep reading for the details.

What is MTTR?

MTTR is the average time from detection of an incident to restoration of the integration’s defined operational state.

MTTR = Average(recovery time − detection time)

Define both timestamps before measuring:

Detection – An automated signal, alert delivery, team awareness, or customer report (depending on the question you are answering).
Recovery – A defined operational condition. For example, when new executions succeed again and the integration has returned to its normal operating state.

Use the same start and end events consistently. Changing those definitions can make it look as though there’s been a change in integration performance when that’s not the case.

Recovery is not data reconciliation

An integration can return to normal operation while historical records remain incomplete or out of date.

For example, resolving an expired credential may restore successful new executions without repairing records that failed during the outage. Track that separately:

MTTR measures time to restore normal integration operation.
Time to data reconciliation measures time to restore affected customer data.

Keeping these measures separate prevents operational recoveries from hiding customer data issues.

Why MTTR matters

High MTTR may reflect more than a slow implementation process. It can reveal:

Slow or incomplete diagnosis
Unclear ownership
Missing/incomplete runbooks
Restricted access to logs or customer context
Error categories that do not map to a clear response procedure

Use MTTR as a diagnostic measure and not only a scorecard number. Segment it as necessary to find where recoveries are most inefficient (require the most time).

How to measure MTTR

1. Define detection and recovery

Choose the detection event that matches your question. Use an actionable alert to evaluate monitoring, or team awareness to evaluate operational response. Do not blend those events into one timestamp.

Document what counts as recovery. A practical condition is restored normal execution: new executions succeed and the integration has returned to its defined operational state.

2. Record the incident timeline

Capture these timestamps when available:

Detection
Acknowledgment
Diagnosis
Mitigation
Recovery
Data reconciliation

MTTR uses detection and recovery directly. The other timestamps explain where the response slows down (for example, whether the delay is in alert response, diagnosis, mitigation, or restoration).

3. Summarize the distribution

Calculate recovery time for each incident. Report the median and p90 as primary views, and retain the mean for comparability.

Segment results by:

Severity
Error category
Integration
Resolver group
Time period

A portfolio average can hide one integration, customer, or incident category with recovery times that are outside the normal limits.

What Prismatic provides versus what you define

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

Step-level logs and searchable execution history
Instance context for the affected integration and customer
Configured retry and replay processes
Configured alert webhook payloads with incident context such as the instance, customer, execution, flow, trigger, and step
External log streaming for longer-term analysis, when enabled on the plan

These capabilities can support faster diagnosis and recovery, but they do not define MTTR automatically for every environment.

Your team still defines:

Detection and recovery events
Inclusion and exclusion rules
Severity and error categories
Resolver-group ownership
Data-reconciliation measurement
Targets for each integration or workflow

Where to start

If you are measuring MTTR from scratch:

Start with the failure types that matter most to customers.
Define observable detection and recovery events.
Record response timestamps separately.
Establish a baseline over a recent rolling window.
Report median, p90, and mean.
Segment results by severity, error category, integration, and resolver group.
Review the longest incidents for missing/incomplete runbooks, ownership gaps, and insufficient context.