Postmortem Multi-Team Contributing Factors Untangler Prompt
Untangle the contributing factors in an incident that crossed service and team boundaries — attributing factors to systems, not people, and mapping the seams where handoffs and ownership gaps let it propagate.
- Target user
- Incident commander / SRE leading a cross-team post-incident review
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a staff SRE who facilitates post-incident reviews that span multiple services and teams. You know the political trap: each team wants the cause to live in someone else's system. Your job is to map the contributing factors across boundaries fairly, with the focus on seams and systems rather than which team to blame. I will paste: [INCIDENT TIMELINE: how the failure originated and propagated across services] [SERVICES / TEAMS INVOLVED: the systems in the path and who owns each] [HANDOFF POINTS: API contracts, queues, on-call boundaries, and escalation paths between them] Do the following: 1. Map propagation: trace how the failure moved from service to service, marking where it was amplified, masked, or could have been contained. 2. Attribute contributing factors to systems and seams, not teams: for each factor, name the technical or process condition (a missing backpressure, an unvalidated contract, an ambiguous ownership boundary). Use roles, never individuals. 3. Highlight the seams: identify the inter-team handoffs where assumptions diverged — what Team A assumed about Team B's behavior that did not hold. 4. Find ownership gaps: surface any failure mode that fell between teams with no clear owner, and any conflicting assumptions about who was responsible. 5. Balance attribution: explicitly check that you are not over-weighting whichever team's logs are most detailed. Note where data is missing from a team's side and mark it [UNVERIFIED]. Output format: a propagation diagram described in steps, then a contributing-factors table (Factor / System or seam / Defense it would add / Owning role), and a short list of the cross-team seams that need a clear owner. Guardrails: stay strictly blameless and balanced — frame everything as systems and boundaries, never as a team's failing. Mark any cross-team claim you cannot verify from the pasted data as [UNVERIFIED]. The participating teams own validation of their own systems; I own the final document.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Multi-team incidents are the hardest postmortems to run honestly. A failure that crosses service boundaries arrives at the review with each team already holding a story in which the root cause lives somewhere else. Left unmanaged, the review becomes a negotiation over whose logs win, and the actual lesson — the seam where assumptions diverged — never gets written down.
This prompt keeps the analysis on systems and boundaries by design. It traces propagation across services, then attributes every contributing factor to a technical or process condition rather than a team, and it specifically hunts for the two things cross-team incidents are made of: handoff points where one service assumed something untrue about another, and ownership gaps where a failure mode belonged to no one. Those seams are usually the real fix, and they are exactly what single-team framing hides.
The balance check is what makes it fair. The team with the most detailed telemetry tends to look most culpable simply because more of its behavior is visible, so the prompt forces an explicit note where a team’s data is missing and marks those claims unverified. Attribution stays at the level of roles and systems, validation of each system stays with its owning team, and the final document stays with the human facilitator.
Related prompts
-
Postmortem Findings to Engineering Tickets Prompt
Convert postmortem findings into well-scoped engineering tickets — each with a clear title, candidate owner role, acceptance criteria, defense type, and a realistic due date — so the lessons turn into tracked work instead of a buried action-items list.
-
Postmortem Participant Interview Question Generator Prompt
Generate tailored, blameless interview questions for each person who was involved in an incident — so the facilitator can surface contributing factors, decision context, and 'what made sense at the time' before drafting the postmortem.
-
Postmortem Contributing Factors vs Root Cause Classifier Prompt
Sort a postmortem's tangle of causes into the true root cause, the contributing factors, the proximate trigger, and the mitigating factors, so the document fixes the systemic source instead of stopping at the first plausible explanation.
-
Postmortem Assumptions and Unknowns Extractor Prompt
Read a postmortem draft and surface every unstated assumption and open unknown that is being treated as settled fact, so the root-cause analysis and action items don't quietly rest on unverified claims.
More Post Mortems with AI prompts & error guides
Browse every Post Mortems with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.