> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/chaos-faults.md).

# Chaos faults

## AWS <a href="#aws" id="aws"></a>

## Azure <a href="#azure" id="azure"></a>

## Cloud-Foundry <a href="#cloud-foundry" id="cloud-foundry"></a>

## GCP <a href="#gcp" id="gcp"></a>

## Kube-Resilience <a href="#kube-resilience" id="kube-resilience"></a>

## Kubernetes <a href="#kubernetes" id="kubernetes"></a>

## Linux <a href="#linux" id="linux"></a>

## Load <a href="#load" id="load"></a>

## Security-chaos <a href="#security-chaos" id="security-chaos"></a>

## VMware <a href="#vmware" id="vmware"></a>

## Windows <a href="#windows" id="windows"></a>

## SSH <a href="#ssh" id="ssh"></a>

## BYOC <a href="#byoc" id="byoc"></a>

Chaos faults are the failures injected into the chaos infrastructure as part of a chaos experiment. Every fault is associated with a target resource, and you can customize the fault using the fault tunables, which you can define as part of the Chaos Experiment CR and Chaos Engine CR.

The fault execution is triggered when the chaos engine resource is created. Typically, the chaos engine is embedded within the **steps** of a chaos fault. However, you can also create the chaos engine manually, and the chaos operator reconciles this resource and triggers the fault execution.

You can customize a fault execution by changing the tunables (or parameters). Some tunables are common across all the faults (for example, **chaos duration**), and every fault has its own set of tunables: default and mandatory ones. You can update the default tunables when required and always provide values for mandatory tunables (as the name suggests).

Various status of chaos faults are described below:

<details>

<summary>Fault Status</summary>

Fault status indicates the current status of the fault executed as a part of the chaos experiment. A fault can have 0, 1, or more associated [probes](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/index.md). Other steps in a chaos experiment include resource creation and cleanup.

In a chaos experiment, a fault can be in one of six different states. It transitions from **running**, **stopped** or **skipped** to **completed**, **completed with error** or **error** state.

* **Running**: The fault is currently being executed.
* **Stopped**: The fault stopped after running for some time.
* **Skipped**: The fault skipped, that is, the fault is not executed.
* **Completed**: The fault completes execution without any **failed** or **N/A** probe statuses.
* **Completed with Error**: When the fault completes execution with at least one **failed** probe status but no **N/A** probe status, it is considered to be **completed with error**.
* **Error**: When the fault completes execution with at least one **N/A** probe status, it is considered to be **error** because you can't determine if the probe status was **passed** or **failed**. A fault is considered to be in an **error** state when it has 0 probes because there are no health checks to validate the sanity of the chaos experiment.

</details>

Below are tables with links to individual fault documentation for easy navigation.

import ChaosFaults from '@site/src/components/ChaosEngineering/ChaosFaults'; import { categories } from './categories';

### Variables <a href="#variables" id="variables"></a>

Variables allow you to define reusable, parameterized values that can be referenced in fault properties during fault configuration. This applies to all fault types.

Variables are useful when you want to:

* **Reuse values** across multiple fault configuration fields without repeating them
* **Inject runtime values** into fault properties at experiment execution time
* **Centralize configuration** - update a variable once and have it reflected wherever it is used

## Adding a Variable <a href="#adding-a-variable" id="adding-a-variable"></a>

When creating or editing a fault, navigate to the **Variables** step and click **+ Add Variable**. Each variable has the following fields:

| Field                                       | Description                                                                  |
| ------------------------------------------- | ---------------------------------------------------------------------------- |
| **Type**                                    | Data type of the variable. Supported types: `String`, `Number`               |
| **Name**                                    | Identifier used to reference the variable in fault properties                |
| **Value**                                   | The value assigned to the variable - can be a fixed value or a runtime input |
| **Set variable as required during runtime** | When checked, the variable must be supplied at experiment run time           |
| **Description**                             | Optional description for the variable                                        |

## Value Types <a href="#value-types" id="value-types"></a>

* **Fixed value** - A static value set at fault creation time. The value remains constant across experiment runs.
* **Runtime input** - The value is provided at experiment execution time (shown as `<+input>`). Use this when the value may differ between runs.

## Using Variables in Chaos Studio <a href="#using-variables-in-chaos-studio" id="using-variables-in-chaos-studio"></a>

When you add a fault to an experiment in the **Chaos Studio**, the fault panel shows a **Variables** tab. Any input variables defined on the fault appear here, allowing you to supply or override values for that specific experiment run before applying changes.