Postmortem Vendor and Third-Party Dependency Incident Analyzer Prompt

You are a senior SRE analyzing an incident that a third-party or vendor dependency triggered or amplified. Your job is to cleanly separate the vendor's behavior from your own system's response, and to keep the team's focus on what it controls, without blaming individuals.

I will paste:
[INCIDENT] — the timeline and impact, including when and how the vendor dependency was involved.
[VENDOR_INFO] — any status-page notes, vendor postmortem, or support-ticket detail.
[OUR_RESILIENCE] — the timeouts, retries, fallbacks, circuit breakers, caches, or multi-region setup that were (or weren't) in place.

Do this:

1. Build a TWO-COLUMN TIMELINE: "What the vendor did" versus "How our system responded," aligned by time.
2. Separate VENDOR-SIDE factors (their outage, their API change, their capacity) from OUR-SIDE factors (missing timeout, unbounded retries, no fallback, hard dependency on a soft feature).
3. Assess RESILIENCE PERFORMANCE: for each protection we had, did it fire, fire too late, or was it absent? Where did a small vendor blip get amplified into a large outage by our own behavior?
4. List CONTROLLABLE ACTIONS: concrete resilience improvements we own (timeouts, circuit breakers, graceful degradation, caching, removing a hard dependency).
5. List VENDOR-MANAGEMENT ACTIONS: SLA follow-ups, escalation contacts, status-page monitoring, contractual or architectural diversification.
6. Note what we CANNOT control and must design around.

Output as Markdown with the two-column timeline plus the lists above. Stay blameless toward both your team and the vendor's engineers; describe systems and contracts, not people. Mark inferences beyond the inputs as [ESTIMATE]. A human owner decides which actions to fund; you only propose them.

Why this prompt works

When a cloud provider, SaaS API, or CDN causes an outage, the tempting conclusion writes itself: the vendor failed, we were victims, action item is “wait for them to fix it.” That framing feels satisfying and is almost always the least useful reading of the incident. Nearly every vendor-triggered outage is really two failures stacked on top of each other: the vendor’s fault, and the absence or misbehavior of the resilience that should have contained it. A brief dependency blip only becomes a customer-facing outage because something on your side, an unbounded retry loop, a missing timeout, a hard dependency on a feature that should have been optional, amplified it. This prompt forces that second, more actionable failure into the light.

The two-column timeline is the central device. By aligning “what the vendor did” against “how our system responded” moment by moment, the analysis makes amplification visible: you can literally see the point where a degraded upstream turned into a saturated thread pool, or where a slow API with no timeout cascaded into your own request queue backing up. That visual separation is what stops the postmortem from terminating at “vendor outage” and pushes it toward the retry-storm or missing-circuit-breaker that your team actually owns. Splitting factors into vendor-side and our-side, then assessing whether each protection fired, fired late, or was absent, converts a vague sense of “we should be more resilient” into a specific inventory of what to build.

The blameless requirement extends in an unusual direction here: it protects the vendor’s engineers too. It is easy to write a postmortem that vents at a provider, but that produces heat rather than action, and it often rests on guesses about what happened inside a system you cannot see. Keeping the language at the level of systems and contracts, and refusing to assert vendor internals beyond their published notes, keeps the analysis honest and keeps the focus where leverage exists. Blaming the vendor is comfortable precisely because it absolves your team of the harder work of building containment.

The controllable-versus-uncontrollable split is what makes the output usable by leadership. Resilience work costs money and complexity, and a diversified multi-region or multi-vendor posture is not always worth it; those are funding decisions a human owner must make with real cost and dependency data. The prompt’s role is to lay out the menu, clearly marking what the team can control, what it must manage through the vendor relationship, and what it simply has to design around, while [ESTIMATE] tags keep it from overstating vendor behavior it can only infer.