# Incident Postmortem Prover MCP for AI Agents AI Agent Connect

> Incident Postmortem Prover forces SRE-grade rigor onto your incident reports. Most teams settle for vague timelines and surface-level causes that let the same bugs return months later. This Connector ensures every postmortem includes a minute-by-minute reconstruction, a deep 5-Whys chain to find systemic organizational roots, and action items with clear owners, deadlines, and success metrics. It moves you from just telling a story to actually fixing the underlying process.

## Overview
- **Category:** productivity
- **Price:** Free
- **Endpoint:** https://edge.vinkius.com/vk_preview_KJycaUpjREM4styaMUmvRCfmlrKrfVMXPwF6uM9b/ai-agent-connect
- **Tags:** incident-postmortem, root-cause-analysis, sre, five-whys, blameless-postmortem, action-items, pattern-detection, timeline-reconstruction

## Description

When a major outage happens, the pressure to get back online is huge. Often, the postmortem that follows is just a summary of what went wrong, rather than a deep dive into why it happened in the first place. You end up with "band-aid" fixes like "add more monitoring" and the same issue pops up again three months later because the actual process failure was never addressed. This Connector changes that dynamic by acting as a rigorous peer reviewer for your engineering team. Instead of letting a narrative slip by, it forces you to account for every minute of the incident, pushing past the "the system crashed" symptom to find the cultural or systemic incentives that allowed the crash to occur. It demands specific, measurable action items that actually have a name and a date attached to them. By using this through the Vinkius catalog, you can ensure that every incident leads to a measurable improvement in your infrastructure's reliability. It turns your postmortem process from a checkbox exercise into a high-fidelity investigation that prevents history from repeating itself. It ensures that your team isn't just documenting the past, but actively engineering the future. You get a standardized way to verify that your investigations meet high-quality standards, making sure that every minute of downtime is converted into a permanent fix rather than a temporary patch. This level of rigor is what separates high-performing engineering organizations from those that constantly fight the same fires.

## Tools

### validate_incident_postmortem
This tool checks your postmortem for minute-by-minute timeline gaps and ensures you've reached a systemic root cause. It forces you to include specific owners and success metrics for every action item to prevent recurring issues.

## Prompt Examples

**Prompt:** 
```
Our API had a 500 error spike during the 2 PM deploy. We rolled back and it's fixed now. Can you check if our postmortem is good enough?
```

**Response:** 
```
The current summary is too thin for a rigorous investigation. While you noted the start and end, you're missing the minute-by-minute details between 2:00 and 2:45. What happened at 2:10? Was there a specific alert? To make this SRE-grade, you'll need to account for every action taken or decision made during that window.
```

**Prompt:** 
```
We decided the root cause was that an engineer forgot to update a config file. Is that a valid root cause?
```

**Response:** 
```
Actually, 'forgetting a config' is usually a symptom of a process failure, not the root cause. To find the systemic issue, we should ask: Why was the config managed manually? Why didn't the deployment pipeline catch the missing update? The root cause is likely a lack of automated configuration validation.
```

**Prompt:** 
```
We need to fix our deployment errors. Can we add 'better testing' to our action items?
```

**Response:** 
```
That's a bit too vague to be actionable. To ensure this actually gets done, we need to define it using a specific owner, a deadline, and a success metric. For example: '[DevOps Team] [By Friday] [Implement automated integration tests for the payment path] [Success: 100% pass rate in staging before deploy].'
```

## Capabilities

### Reconstruct incident timelines
Generate a minute-by-minute account of every alert, action, and decision.

### Trace systemic root causes
Apply a 5-Whys chain to move past symptoms to organizational and process roots.

### Isolate enabling causes
Separate the core root cause from the various factors that amplified the incident.

### Create actionable items
Enforce owners, deadlines, and success metrics for every postmortem task.

### Detect recurrence patterns
Cross-reference historical incidents to identify repeating service or team issues.

## Use Cases

### Outage Analysis
An SRE provides a messy timeline of a database failure; the agent identifies a 15-minute gap where no actions were logged.

### Action Item Audit
A team submits 'improve testing' as a fix; the agent rejects it for lacking an owner and a measurable success criterion.

### Root Cause Deep Dive
After a deployment error, the agent pushes back on 'human error' to find the lack of automated configuration validation.

### Pattern Detection
A manager asks if this is a new issue; the agent cross-references history to show it's the third time this team hit a memory leak.

## Benefits

- Stop repeating the same mistakes by using validate_incident_postmortem to identify recurring patterns in your incident history.
- Eliminate vague "band-aid" fixes with action items that require a specific owner, deadline, and success metric.
- Move beyond surface-level symptoms by forcing a 5-Whys chain that reaches organizational or systemic roots.
- Close investigation gaps by ensuring every minute of an outage is accounted for in your reconstructed timeline.
- Distinguish between what caused an incident and what just made it worse by separating root causes from contributing factors.

## How It Works

The bottom line is that it turns a simple summary into a rigorous, actionable engineering investigation.

1. Provide the raw notes or narrative from your incident.
2. The Connector analyzes the data against SRE rigor standards.
3. You get a verdict on missing gaps, shallow causes, or vague actions.

## Frequently Asked Questions

**Does Incident Postmortem Prover help with SRE standards?**
Yes, it enforces the specific rigor required for high-maturity SRE teams, including 5-Whys chains and minute-by-minute timelines.

**How does Incident Postmortem Prover find root causes?**
It pushes your AI client to look past symptoms (like a crash) to find the underlying process, incentive, or cultural reasons why the crash happened.

**Can Incident Postmortem Prover help with action items?**
Yes, it ensures every task has an owner, a deadline, and a measurable success metric so that "band-aid" fixes don't get ignored.

**Will Incident Postmortem Prover help me find recurring patterns?**
It cross-references your incident history to see if the same service, cause type, or team has faced similar issues in the past.

**Is Incident Postmortem Prover good for blameless postmortems?**
It's designed specifically for blameless cultures by shifting the focus from 'who did it' to 'what process failed' and how to fix it.

**What happens if my timeline has gaps?**
The Connector will flag those gaps as process failures, forcing you to investigate what happened during those missing minutes.

**What makes a timeline 'complete'?**
Minute-by-minute entries from first alert to full resolution. Each entry: [HH:MM] [Actor] [Action] [Outcome]. 'Around 3 PM' is rejected. '15:03 — PagerDuty alert fired for p95 > 2s on /api/orders' is accepted.

**How deep should the 5 Whys analysis go?**
Until you reach a SYSTEMIC root — not a human error. 'Bob forgot to restart' is blame. 'The deployment pipeline has no post-deploy health check' is a system fix. The 5th Why should expose a process, architecture, or policy gap.

**What makes an action item 'accountable'?**
Three requirements: (1) Named owner — not 'the team'. (2) Deadline — not 'soon'. (3) Success metric — not 'improved'. Example: 'Owner: @maria, Deadline: 2024-02-15, Metric: p95 latency < 500ms for 7 consecutive days.'