Third-Party Dependency Failure Simulation Prompt

This prompt is designed for resilience engineers and SREs who need to move beyond generic 'what if the payment gateway goes down?' discussions and into concrete, executable failure injection scenarios. The job-to-be-done is translating a system architecture diagram and a list of external dependencies into a precise test plan that specifies latency injection ranges, error rate targets, timeout configurations, and the expected behavior of circuit breakers, retry logic, and fallback mechanisms. The ideal user has a working knowledge of their system's dependency graph and can provide context on existing resilience patterns, but needs help generating the specific parameters that make a chaos experiment or failure test both realistic and safe to execute.

You should use this prompt when you have a defined system boundary and a known set of third-party services (APIs, databases, message queues, cloud services) that your application depends on. It is particularly valuable during pre-release resilience reviews, when onboarding a new critical dependency, or when designing chaos engineering game days. The prompt requires you to supply a structured [DEPENDENCY_MAP] detailing each service, its criticality, and its current timeout and retry configuration. Without this input, the model will make assumptions that could lead to unrealistic or unsafe test scenarios. The output is not a runnable script but a detailed scenario specification that a human or an automation harness can translate into a fault injection tool like Gremlin, Chaos Mesh, or AWS FIS.

Do not use this prompt for systems where you have no visibility into the dependency chain or where the architecture is entirely undocumented. It is also not a substitute for a full threat model or a security-focused failure analysis. The prompt assumes you are testing for availability and performance degradation, not for malicious compromise or data corruption attacks. After generating the scenario, you must review the proposed injection parameters against your actual production configurations; a model cannot know your exact network topology or rate-limiting rules. The next step is to take the generated scenario and run it in a pre-production environment, using the provided eval checks to validate that the simulated failures trigger the expected circuit breaker and fallback behaviors without causing unexpected cascading failures.

This prompt template produces a failure injection scenario for a specified third-party dependency. It guides the model to define latency injection ranges, error rate targets, timeout configurations, and expected circuit breaker or fallback behavior. Use it when you need a structured, repeatable way to generate resilience test scenarios for external service degradation. Do not use this prompt for internal service failures, infrastructure-level chaos experiments, or scenarios where the dependency's internal implementation details are required—those require different context and injection models.

Below is the copy-ready prompt template. Replace each square-bracket placeholder with your specific context before sending it to the model. The placeholders control the dependency scope, failure dimensions, and output structure. After the code block, adaptation guidance explains how to adjust the template for different resilience testing needs.

codeCopy
You are a resilience engineer designing a failure injection scenario for a third-party dependency.

Generate a structured failure simulation scenario for the following dependency:

[DEPENDENCY_NAME]
[DEPENDENCY_DESCRIPTION]
[DEPENDENCY_CRITICALITY: critical | high | medium | low]

Include these failure dimensions with specific, testable parameters:

1. Latency Injection
   - Baseline latency (p50, p95, p99) in milliseconds
   - Injected latency range (min, max, step) in milliseconds
   - Injection duration and ramp profile
   - Which endpoints or operations receive latency injection

2. Error Injection
   - Error types to inject (timeout, 5xx, connection refused, DNS failure, TLS error)
   - Error rate targets (percentage of requests)
   - Error rate ramp profile (instant, gradual, oscillating)
   - Which endpoints or operations receive error injection

3. Timeout Configuration
   - Current client-side timeout settings
   - Recommended timeout adjustments for the test
   - Connection pool timeout settings
   - Request queue timeout settings

4. Expected System Behavior
   - Circuit breaker state transitions and timing
   - Fallback mechanism activation criteria
   - Expected degradation mode (graceful, partial, full outage)
   - Recovery behavior after injection stops
   - Metrics to monitor during the test

5. Test Execution Parameters
   - Steady-state traffic level during injection
   - Injection start and stop triggers
   - Abort conditions and safety thresholds
   - Rollback procedure if system becomes unstable

[ADDITIONAL_CONTEXT]
[CONSTRAINTS]

Output the scenario as a structured JSON object with the following schema:

[OUTPUT_SCHEMA]

Include a "risk_assessment" field that identifies:
- Potential cascading failures
- Data consistency risks
- Monitoring blind spots
- Recommended pre-test checks

To adapt this template, start by narrowing the failure dimensions to match your actual dependency surface. If the dependency has a well-defined API with known endpoints, replace the generic endpoint placeholders with specific paths or operation names. For dependencies with client libraries, include the library version and known timeout defaults in [ADDITIONAL_CONTEXT]. When testing circuit breakers, ensure [CONSTRAINTS] specifies the circuit breaker library (e.g., Resilience4j, Polly, Hystrix) and its configuration so the model can produce accurate state transition predictions. For high-risk production tests, add a human review step before execution: the generated scenario should be reviewed by a senior engineer who can validate that the injection parameters won't cause unrecoverable data corruption or cascade beyond the intended blast radius.

Before using this prompt in a test pipeline, validate the output against these criteria: every injection parameter must have a numeric range or specific value, not a vague description; the expected behavior section must reference specific circuit breaker or fallback mechanisms named in your [ADDITIONAL_CONTEXT]; the abort conditions must include concrete metric thresholds (e.g., 'abort if p99 latency exceeds 5000ms for 30 seconds'); and the risk assessment must identify at least one monitoring blind spot. If the model output fails any of these checks, re-prompt with more explicit constraints or narrow the scope to a single failure dimension. For production use, store generated scenarios in version control alongside the prompt version that produced them, enabling traceability when scenarios are reused or modified.

This prompt is designed to be integrated into a resilience engineering workflow, not used as a one-off chat. The primary integration point is a CI/CD pipeline stage or a chaos engineering platform that consumes structured failure injection scenarios. The application should supply the prompt with a system architecture document, a service dependency graph, and the target SLA or SLO definitions as [CONTEXT]. The model's output—a JSON array of failure scenarios—must be validated against a strict schema before any failure is injected into a live environment. Treat the model as a scenario generator, not an authority; every generated scenario must pass automated validation and, for production environments, a human approval step.

Wire the prompt into an application by first constructing the [CONTEXT] block programmatically. This block should be assembled from your service registry, distributed tracing data (e.g., Jaeger or Zipkin traces showing actual dependency call paths), and your incident response runbooks. The [CONSTRAINTS] placeholder should be populated with your organization's specific blast radius policies, allowed injection types (latency, error codes, connection drops), and any regulatory boundaries. After the model returns the JSON output, run a validation layer that checks: (1) every dependency in the scenario exists in your service graph, (2) latency injection ranges do not exceed your configured timeouts, (3) error rate targets are within the circuit breaker thresholds you have actually configured, and (4) recovery assumptions reference real fallback mechanisms you have implemented. Reject any scenario that references a non-existent fallback or an unrealistic recovery time. Log every generated scenario, validation result, and human approval decision for auditability.

For high-risk production environments, insert a mandatory human review step before any failure injection executes. The review interface should display the generated scenario alongside the source evidence from your service graph that supports each dependency claim. Use a model with strong JSON mode and low temperature (0.1–0.2) for this task; avoid models prone to hallucinating plausible-sounding but non-existent API endpoints. Implement a retry loop with a maximum of two retries if validation fails, using the validation errors as feedback in the retry prompt. If the model consistently generates scenarios that fail validation, escalate to a human resilience engineer rather than silently discarding outputs. The next step after a validated scenario is to feed it into your chaos engineering tool (e.g., Gremlin, Chaos Mesh, or LitmusChaos) with the abort conditions and monitoring thresholds already defined in the scenario output.