Controlling faults

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 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 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:

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.
To pause fault injection at the end of a test timeline, use an eventually or finally 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 for more details.

Understanding what faults occurred

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

In the Triage report, as fault-injection events, next to your application’s logs and any assertion outcomes.
In the Logs Explorer, filterable by the fault injector category. The fault logs reference explains the logging format.
In the API responses that return logs, as events whose source.name is fault_injector.