> ## Controlling faults

> Overview of the types of faults that the fault injector produces, including network faults, node failures, and thread pausing

> Fetch the complete documentation index at: https://antithesis.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

---

The Antithesis fault injector continuously disrupts the environment that your software runs in. The following types of faults are available in Antithesis:

| Type | Enabled by default? | Examples |
| --- | --- | --- |
| Network | Yes | Baseline latency, partitions, clogs, restore |
| Node | No | Node pause, node kill / stop, node throttling |
| Clock | No |  Forward/backward clock skips |
| Other | No |  Thread pausing, CPU modulation, custom faults |

See [Types of faults](/docs/product/fault_injection/fault_types/) for more details on each fault type, and on how faults overlap.

## Enabling faults

The default Antithesis `basic_test` runs with all network faults enabled.

You can enable thread pausing by [instrumenting](/docs/reference/instrumentation/coverage_instrumentation/) your code. To enable node faults, clock jitter, or custom faults, talk to your forward-deployed engineer.

## Pausing faults

By default, faults are injected throughout the test timeline, interleaved randomly with your workload.

There are two ways to pause fault injection:

1. To pause fault injection during a test timeline, call the `ANTITHESIS_STOP_FAULTS` binary from your test command or workload to request a quiet period for a given duration. Antithesis injects this binary on every container or pod path. Antithesis will pause faults, restore killed containers or pods and not inject any faults for the requested duration.
2. To pause fault injection at the end of a test timeline, use an [`eventually`](/docs/product/test_templates/test_composer_reference/#eventually-command) or [`finally`](/docs/product/test_templates/test_composer_reference/#finally-command) test command. These commands create a terminal pause at the end of a timeline, giving the system under test time to recover before final validation checks.

See [Pausing faults](/docs/product/fault_injection/pause_faults/) for more details.

## Understanding what faults occurred

Information about faults appears in three places after a run completes:

- In the [Triage report](/docs/product/reports/), as fault-injection events, next to your application's logs and any assertion outcomes.
- In the [Logs Explorer](/docs/product/logs_explorer/), filterable by the `fault injector` category. The [fault logs reference](/docs/reference/event_logs/#fault-injector-logs) explains the logging format.
- In the [API](/docs/reference/rest_api/) responses that return logs, as events whose `source.name` is `fault_injector`.