API Resilience Tester
Verify documented invariants under controlled failure without causing a retry storm.
Inputs and evidence
Require the resilience requirements, dependency map, target environment, injection method,
monitoring access, and owner-approved safety budget. Mark unspecified retry counts, timeouts,
rate limits, idempotency guarantees, and recovery objectives Not specified.
Workflow
- Extract documented failure modes, client behavior, service behavior, and invariants.
- Define one controlled fault and injection point per scenario.
- Specify observable response, state, recovery, duplication, and telemetry evidence.
- Set request and concurrency budgets, abort conditions, monitoring, rollback, and cleanup.
- Order proposed runs from the smallest probe to any sustained or concurrent scenario.
- HUMAN REVIEW GATE (mandatory). Obtain service-owner approval of the environment,
fault injection, budgets, timing, monitoring, and rollback before execution.
Output shape
| Fault |
Injection point |
Expected behavior |
Invariant |
Abort condition |
Evidence |
Include prerequisites, safety budget, rollback, unknown guarantees, and review decision.
Guardrails
- Never inject failure or concurrency into production or shared dependencies without explicit approval.
- Never invent retry counts, timeouts, status codes, rate limits, or recovery results.
- Prevent unbounded retries and stop immediately when an approved abort condition is met.
- Redact secrets and sensitive payloads; use synthetic data.
- Never claim idempotency, exactly-once behavior, or recovery without observed evidence.
1---2name: api-resilience-tester3description: Plan controlled API resilience tests for timeouts, retries, throttling, duplicate delivery, dependency failures, idempotency, and recovery. Use when asked to test 429 handling, retry behavior, duplicate submissions, partial failure, or fault recovery. Produce a bounded fault matrix and safe runbook rather than an unapproved chaos run.4license: MIT5---67# API Resilience Tester89Verify documented invariants under controlled failure without causing a retry storm.1011## Inputs and evidence1213Require the resilience requirements, dependency map, target environment, injection method,14monitoring access, and owner-approved safety budget. Mark unspecified retry counts, timeouts,15rate limits, idempotency guarantees, and recovery objectives `Not specified`.1617## Workflow18191. Extract documented failure modes, client behavior, service behavior, and invariants.202. Define one controlled fault and injection point per scenario.213. Specify observable response, state, recovery, duplication, and telemetry evidence.224. Set request and concurrency budgets, abort conditions, monitoring, rollback, and cleanup.235. Order proposed runs from the smallest probe to any sustained or concurrent scenario.246. **HUMAN REVIEW GATE (mandatory).** Obtain service-owner approval of the environment,25 fault injection, budgets, timing, monitoring, and rollback before execution.2627## Output shape2829| Fault | Injection point | Expected behavior | Invariant | Abort condition | Evidence |30|---|---|---|---|---|---|3132Include prerequisites, safety budget, rollback, unknown guarantees, and review decision.3334## Guardrails3536- Never inject failure or concurrency into production or shared dependencies without explicit approval.37- Never invent retry counts, timeouts, status codes, rate limits, or recovery results.38- Prevent unbounded retries and stop immediately when an approved abort condition is met.39- Redact secrets and sensitive payloads; use synthetic data.40- Never claim idempotency, exactly-once behavior, or recovery without observed evidence.
PramodDutta