Dependency Failure Propagation Prompt

Use this prompt when an incident involves multiple services and you need to understand how a failure in one component propagated through the dependency graph. This is not a root cause prompt for a single service failure. It is designed for platform engineers and SREs who already have a known originating failure and need to map the cascading impact across services, identify amplification points where failures were magnified, and determine the full blast radius including timing and severity per affected service. The prompt assumes you have a service dependency graph, incident timeline data, and per-service health metrics available as input context. It does not replace human architecture knowledge but accelerates the structured analysis that would otherwise require manual correlation across dashboards and runbooks.

The ideal user is a platform engineer or SRE who has already identified the initial failing component and needs to answer 'what else broke because of this?' before the incident review meeting. Required context includes a machine-readable or clearly described service dependency graph, a normalized incident timeline with timestamps, and per-service health metrics (error rates, latency, saturation) for the incident window. Without these inputs, the prompt will produce speculative or incomplete propagation maps. Do not use this prompt when the originating failure is unknown, when only a single service is affected, or when you lack dependency graph data—those scenarios require root cause analysis or single-service debugging prompts instead.

The prompt outputs a structured propagation map with timing and impact severity per service, but it is not a substitute for architecture review. Always validate the output against your own understanding of the system's critical paths and known failure modes. The prompt may miss indirect dependencies, asynchronous side effects, or human-in-the-loop mitigations that are not represented in the provided graph. Use the output as a starting point for discussion, not as the final incident record. For high-severity incidents, pair this prompt's output with a manual review by the service owners before publishing the blast radius analysis.

This template is the core of the Dependency Failure Propagation playbook. It is designed to be copied directly into your AI harness, IDE, or orchestration layer. The prompt instructs the model to act as a platform engineer analyzing a cascading failure. It requires a structured [SERVICE_DEPENDENCY_GRAPH], an [INCIDENT_TIMELINE], and a set of [OBSERVED_SYMPTOMS] to produce a detailed propagation map. Before using this prompt, ensure you have assembled these inputs from your service catalog, monitoring tools, and incident channel. The prompt's value lies in its strict output schema, which forces the model to reason about timing, directionality, and amplification points rather than producing a vague narrative.

textCopy
You are a principal platform engineer investigating a cascading failure across a distributed system. Your task is to trace the propagation of a failure through a service dependency graph, identify the blast radius, and pinpoint amplification points.

## INPUT DATA

### Service Dependency Graph
[SERVICE_DEPENDENCY_GRAPH]
# Provide a structured representation of your service topology. This can be a JSON object, a list of directional edges (e.g., ServiceA -> ServiceB), or a textual description of dependencies, health-check configurations, and timeouts.

### Incident Timeline
[INCIDENT_TIMELINE]
# A chronologically ordered list of events, including deployment timestamps, alert firing times, metric spikes, and manual interventions. Use the format: [Timestamp] [Event Description].

### Observed Symptoms
[OBSERVED_SYMPTOMS]
# A list of user-facing and internal symptoms, such as elevated error rates, latency spikes, queue backlogs, or specific error messages. Include the affected service and the time the symptom was first observed.

## CONSTRAINTS
- Base your analysis strictly on the provided graph, timeline, and symptoms. Do not invent services or events.
- Distinguish between a service being the *root cause* and a service being an *amplification point* (e.g., a service that failed due to a lack of a circuit breaker).
- For each impacted service, state the direction of failure propagation.
- If the provided data is insufficient to determine a causal link, explicitly state that uncertainty.

## OUTPUT SCHEMA
Respond with a single JSON object conforming to the following structure. Do not include any text outside the JSON object.
{
  "propagation_map": [
    {
      "impacted_service": "string",
      "failure_source": "string", // The immediate upstream dependency that caused the failure
      "propagation_mechanism": "string", // e.g., 'timeout', 'error propagation', 'connection pool exhaustion', 'cascading backpressure'
      "first_observed_impact_timestamp": "string",
      "severity": "critical" | "degraded" | "unaffected",
      "amplification_point": true | false,
      "amplification_detail": "string", // Explain why it's an amplification point, e.g., 'Missing circuit breaker caused thread pool exhaustion'
      "evidence": ["string"] // List of specific timeline events or symptoms supporting this finding
    }
  ],
  "critical_path_impact": "string", // Summary of how a critical user journey or business function was broken
  "unaffected_services": ["string"], // List of services in the graph that were not impacted
  "analysis_confidence": "high" | "medium" | "low",
  "uncertainty_notes": ["string"] // List of specific questions that need more data to answer
}

To adapt this template, replace the bracketed placeholders with real data from your incident. The [SERVICE_DEPENDENCY_GRAPH] is the most critical input; a machine-readable format like a JSON adjacency list will yield more reliable results than a paragraph of text. If you are wiring this into an automated incident analysis pipeline, the [INCIDENT_TIMELINE] and [OBSERVED_SYMPTOMS] can be programmatically assembled from PagerDuty alerts, Slack transcripts, and Datadog event streams. After receiving the output, you must validate the JSON schema and verify that every propagation_mechanism and evidence field is grounded in the input data you provided. For high-severity incidents, this analysis is a starting point for human discussion, not a final verdict.

This prompt is designed to be called during an active incident or post-incident review, not as a one-off chat interaction. It expects a structured service dependency graph and a failure origin point as input. The output is a propagation map that your application can render as a directed graph, a table, or an alert payload. The primary integration points are your service catalog, your real-time topology data (from a tool like ServiceNow, Backstage, or a CMDB), and your incident management platform (PagerDuty, FireHydrant, etc.). The prompt should be invoked automatically when a critical service degradation is declared, with the dependency graph fetched from the system of record rather than pasted by a human operator.

Build a thin API wrapper that accepts an incident ID, fetches the current dependency graph from your service catalog API, identifies the originating failed service from the incident's affected_component field, and assembles the prompt with the [DEPENDENCY_GRAPH] and [FAILURE_ORIGIN] placeholders populated. Validate the input graph structure before sending: every node must have a name and depends_on list, and the origin node must exist in the graph. If validation fails, return a structured error to the caller rather than sending a malformed prompt. For model selection, use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro) because the task requires multi-hop graph traversal and impact reasoning. Set temperature=0 or very low to ensure deterministic propagation paths. Implement a retry wrapper with up to 2 retries on 5xx or timeout errors, but do not retry on 4xx validation failures.

The output must be validated against a schema before it enters any downstream system. Require that the propagation_map array contains at least the origin service, that every impacted_service name matches a node in the input graph, and that propagation_path entries form valid edges in the dependency graph. If the model returns a service not present in the input, flag it as a hallucination and either retry or escalate for human review. Log every invocation with the input graph hash, the origin service, the model version, and the output propagation map for post-incident auditability. In high-severity incidents, route the output to a human incident commander for confirmation before triggering automated remediation actions such as circuit breaker flips or traffic shedding. The propagation map should be rendered in your incident dashboard as a visual graph with color-coded severity levels, allowing responders to see the blast radius at a glance. Avoid using this prompt for low-severity or transient blips where the dependency graph is stable and the propagation path is already well-understood; in those cases, a simpler rule-based traversal of the graph is faster and cheaper.