| name | incident-metrics-review |
| enabled | true |
| description | Use when performing incident metrics review — incident response metrics
analysis framework covering MTTR (Mean Time to Resolve), MTTA (Mean Time to
Acknowledge), MTBF (Mean Time Between Failures), and MTTD (Mean Time to
Detect). Provides calculation methods, benchmarking guidance, trend analysis
templates, and actionable improvement recommendations for each metric.
|
| required_connections | [{"prefix":"slack","label":"Slack (for metrics reporting)"}] |
| config_fields | [{"key":"team_name","label":"Team Name","required":true,"placeholder":"e.g., Platform Engineering"},{"key":"review_period","label":"Review Period","required":true,"placeholder":"e.g., Q4 2024, January 2024"},{"key":"incident_source","label":"Incident Data Source","required":false,"placeholder":"e.g., PagerDuty, OpsGenie, Jira"}] |
| features | ["INCIDENT"] |
Incident Metrics Review
Team: {{ team_name }} | Period: {{ review_period }}
Data Source: {{ incident_source }}
Core Metrics Definitions
MTTD — Mean Time to Detect
Time from when an incident begins to when it is detected by monitoring or reported.
Formula: MTTD = Average(detection_time - incident_start_time)
Why it matters: Long MTTD means incidents are silently impacting users before anyone knows.
MTTA — Mean Time to Acknowledge
Time from when an alert fires to when a responder acknowledges it.
Formula: MTTA = Average(acknowledge_time - alert_fire_time)
Why it matters: High MTTA indicates on-call responsiveness issues or alert fatigue.
MTTR — Mean Time to Resolve
Time from incident detection to full resolution.
Formula: MTTR = Average(resolution_time - detection_time)
Why it matters: Primary measure of incident response effectiveness.
MTBF — Mean Time Between Failures
Time between the resolution of one incident and the start of the next.
Formula: MTBF = Average(next_incident_start - previous_incident_resolution)
Why it matters: Low MTBF indicates systemic reliability issues.
Data Collection Template
Incident Log for {{ review_period }}
| # | Incident | Severity | Start Time | Detected | Acknowledged | Resolved | MTTD | MTTA | MTTR |
|---|
| 1 | title | SEV | time | time | time | time | min | min | min |
| 2 | title | SEV | time | time | time | time | min | min | min |
Summary Statistics
| Metric | SEV1 | SEV2 | SEV3 | All |
|---|
| Count | n | n | n | n |
| MTTD (avg) | min | min | min | min |
| MTTA (avg) | min | min | min | min |
| MTTR (avg) | min | min | min | min |
| MTBF (avg) | days | days | days | days |
Benchmarks
Industry benchmarks for reference (adjust based on your context):
| Metric | Excellent | Good | Needs Improvement |
|---|
| MTTD | < 5 min | 5-15 min | > 15 min |
| MTTA | < 5 min | 5-15 min | > 15 min |
| MTTR (SEV1) | < 30 min | 30-60 min | > 60 min |
| MTTR (SEV2) | < 2 hours | 2-4 hours | > 4 hours |
| MTBF | > 30 days | 14-30 days | < 14 days |
Trend Analysis
Month-over-Month Comparison
| Metric | Previous Period | Current Period | Change | Trend |
|---|
| Incident Count | n | n | +/- | improving/stable/declining |
| MTTD | min | min | +/- | improving/stable/declining |
| MTTA | min | min | +/- | improving/stable/declining |
| MTTR | min | min | +/- | improving/stable/declining |
| MTBF | days | days | +/- | improving/stable/declining |
Distribution Analysis
- Incidents by severity: % SEV1, % SEV2, % SEV3, % SEV4
- Incidents by time of day: % business hours, % after-hours, % weekends
- Incidents by service: top 3 services by incident count
- Incidents by root cause category: deployment, infrastructure, dependency, etc.
Improvement Recommendations
If MTTD is High
- Implement synthetic monitoring for critical user journeys
- Add anomaly detection to key business metrics
- Review alert coverage for gaps in observability
- Consider real-user monitoring (RUM) for client-side detection
If MTTA is High
- Review on-call notification channels (push vs. SMS vs. phone)
- Audit alert routing rules for correctness
- Address alert fatigue by reducing false positives
- Review on-call engineer workload and burnout indicators
If MTTR is High
- Invest in runbook automation for common incident types
- Improve diagnostic tooling and dashboards
- Conduct game days to practice incident response
- Review escalation policies for faster expert engagement
- Pre-build rollback procedures for every deployment
If MTBF is Low
- Focus on systemic reliability improvements (redundancy, resilience)
- Review and prioritize postmortem action items
- Invest in chaos engineering to proactively find weaknesses
- Increase test coverage for failure scenarios
Action Items
| Action | Impact on Metric | Effort | Owner | Target Date |
|---|
| action | MTTD/MTTA/MTTR/MTBF | low/med/high | name | date |
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
