Execute a chaos engineering test by injecting failures into a simulation. Can use pre-built scenarios or custom failure injections.

This endpoint works with simulations built on any supported provider, including AWS, GCP, Azure, OCI, and DigitalOcean. When targeting a DigitalOcean-based simulation, failure types such as kill_instance affect Droplets, zone_failure targets DigitalOcean datacenter regions, and database_crash targets Managed Database clusters.

Failure naming surfaces — three zone-related names, three different contexts:

• zone_outage — custom injection type in customInjections[].failureType (this endpoint)
• az_outage — failure type in the synchronous POST /simulations/{id}/failures API
• zone_failure — pre-built scenario ID used in scenarioId

Multi-fault cascade example — inject a zone outage and a database slowdown simultaneously via customInjections to test correlated failure handling:

{
  "simulationId": "sim-abc123",
  "customInjections": [
    { "failureType": "zone_outage", "targetZone": "us-east-1a", "duration": 120 },
    { "failureType": "database_slowdown", "targetResourceId": "db-primary", "intensity": 80, "duration": 120 }
  ]
}

For database_crash custom injections, promotionDelaySeconds (default 30) and restartDelaySeconds (default 1800) are bounded integer simulation-clock assumptions, not measured provider behavior or SLAs. A healthy database explicitly linked by replicaOf promotes after the first delay; without one, the writer restarts after the injection duration plus the second delay. Crashes scheduled for the same simulation instant are considered together: a simultaneously crashed replica is not eligible. In that case the writer uses sole_writer_restart, with promotionUnavailableReason set to related_replica_unavailable_at_injection; a replica lost after promotion was announced instead produces an Explicit replica promotion failed event. multiAz and instanceCount do not imply an eligible replica. The chosen effective values are returned per target in resilienceScore.metrics.databaseCrashAssumptions. While no database serves, positive offered work has 100% errors and zero goodput; promotion restores service without a residual writer-outage penalty. Chaos samples every 10 simulation seconds (default promotion at 30 seconds). Quick inject-failure instead advances one simulation second per step, promotes on the second step (one second after injection), and rejoins after its bounded park window. Compare equivalent unavailable/serving phases, not equal step indices or wall-clock times.

The prebuilt scenarioId: "database_crash" also accepts these two fields at the top level of this request (not inside customInjections). They override only this job, not the saved scenario. Other scenario IDs and custom injections cannot use the top-level fields.

Resilience grade — the grade in the result is derived from the live weighted overall score, including recovery, availability, data integrity, and graceful degradation. Vulnerability findings remain architectural evidence and may be similar across fault combinations, but the grade is not a static SPOF label. To inspect both, pair POST /chaos/run (vulnerability report) with the synchronous POST /simulations/{id}/failures + step-loop pattern (live metrics).

{
  "simulationId": "a638caad-7423-40a3-bb09-f91235d9392d",
  "scenarioId": "zone_failure",
  "duration": 300
}

{
  "jobId": "job-abc123",
  "job": {
    "id": "job-abc123",
    "type": "chaos_test",
    "status": "running"
  },
  "message": "Chaos test job started. Use GET /chaos/jobs/{id} to check status."
}