---
title: Fault Injection
description: Introduces the idea of systematic fault injection that can be used to uncover conflicting failure recovery policies across services.
weight: 40
keywords: [traffic-management,fault-injection]
---

While Envoy sidecar/proxy provides a host of
[failure recovery mechanisms](/docs/concepts/traffic-management/handling-failures/) to services running
on Istio, it is still
imperative to test the end-to-end failure recovery capability of the
application as a whole. Misconfigured failure recovery policies (e.g.,
incompatible/restrictive timeouts across service calls) could result in
continued unavailability of critical services in the application, resulting
in poor user experience.

Istio enables protocol-specific fault injection into the network, instead
of killing pods, delaying or corrupting packets at TCP layer. Our rationale
is that the failures observed by the application layer are the same
regardless of network level failures, and that more meaningful failures can
be injected at the application layer (e.g., HTTP error codes) to exercise
the resilience of an application.

Operators can configure faults to be injected into requests that match
specific criteria. Operators can further restrict the percentage of
requests that should be subjected to faults. Two types of faults can be
injected: delays and aborts. Delays are timing failures, mimicking
increased network latency, or an overloaded upstream service. Aborts are
crash failures that mimic failures in upstream services. Aborts usually
manifest in the form of HTTP error codes, or TCP connection failures.

Refer to [Istio's traffic management rules](/docs/concepts/traffic-management/rules-configuration/) for more details.
