Harness Certified Chaos Engineering key terms

The disciplined practice of running controlled experiments on a system to learn how it behaves when real-world failures occur, so weaknesses are found before customers find them.

A measurable, normal operating condition of a system, expressed as business or technical metrics, that an experiment compares against to decide whether the system behaved acceptably during a fault.

A written, falsifiable statement declaring which metrics define normal behavior and the tolerance range they must stay within; it is validated before, during, and after the injected fault.

A concrete indicator, such as error rate, p99 latency, throughput, or order completion count, used to judge whether the steady-state hypothesis holds during an experiment.

The testable prediction stating what the team expects to happen when a specific fault is injected, including which signals would confirm or refute the expected system behavior.

Deliberately introducing a specific failure condition, such as latency, errors, pod termination, or resource exhaustion, into a system to observe how it responds under stress.

A defined unit of work in a chaos platform that combines a target scope, one or more faults, probe checks, and a duration, and is executed as a tracked run.

A single execution instance of a chaos experiment, with a start time, end time, target set, and recorded results that can be reviewed and compared to earlier runs.

The set of infrastructure, services, and users that could be affected by an experiment; controlling it limits damage if the injected fault reveals a real weakness.

The filter or label query that determines exactly which pods, hosts, services, or namespaces an experiment acts on, keeping the fault confined to intended resources.

Restricting an experiment to a specific Kubernetes namespace, often a non-production or dedicated chaos namespace, so unrelated workloads cannot be selected by the fault.

A rule that automatically stops a running experiment when a defined signal breaches its threshold, such as error rate exceeding a limit or a key service becoming unavailable.

A manual or automated control that immediately halts all active faults and restores normal conditions, used when an experiment causes unexpected or unacceptable impact.

A check executed during an experiment that collects evidence, such as an HTTP request, command, or metric query, and feeds the result into steady-state validation.

The process of comparing probe results and metrics against the declared hypothesis thresholds to confirm the system stayed within acceptable bounds throughout the experiment.

The category of failure an experiment injects, for example network latency, packet loss, HTTP error, CPU stress, memory stress, pod delete, or DNS failure.

A fault category that manipulates network behavior, including added latency, packet loss, corruption, bandwidth limits, and DNS resolution failures between services.

A fault that delays network traffic or responses by a configured amount, used to test timeouts, retries, and user experience under slow dependency conditions.

A network fault that drops a percentage of packets, simulating unreliable links and exposing fragile retry logic, missing timeouts, or chatty protocols.

A fault that consumes CPU, memory, disk, or I/O on a target to simulate saturation and reveal whether limits, autoscaling, and graceful degradation work as intended.

A fault that terminates one or more Kubernetes pods, testing restart behavior, replica redundancy, readiness probes, and whether traffic reroutes without user-visible errors.

A fault that makes a downstream service, database, or third-party API unavailable or erroring, testing fallbacks, circuit breakers, and degraded-mode behavior in the caller.

A resilience pattern that stops sending requests to a failing dependency after a threshold of errors, allowing recovery time and preventing cascading failures.

A failure mode where many clients retry simultaneously after errors, multiplying load on an already struggling dependency and worsening the outage.

The alternative behavior a service uses when its primary dependency fails, such as cached data, a default response, or a queued write, which experiments should verify works.

The ability of a system to keep serving reduced but acceptable functionality when part of it fails, rather than failing entirely for all users.

The degree to which a system's internal state can be understood from its outputs, typically logs, metrics, and traces, which are essential for judging experiment outcomes.

A technique that follows a single request across services using trace and span identifiers, making it possible to see where latency or errors were introduced during a fault.

A quantitative measure of service behavior, such as success rate or response time, that is commonly used as a steady-state metric in chaos experiments.

The amount of unreliability a service is allowed within its objective; chaos experiments are often gated so they consume budget deliberately rather than accidentally.

A planned event where a team runs a series of chaos experiments together, often with observers and a facilitator, to practice response and validate resilience assumptions.

A documented procedure describing how to execute and, if needed, stop an experiment, including who to notify and which signals require immediate rollback.

Restoring the system and experiment configuration to the prior known-good state after a run, including removing injected faults and confirming metrics recovered.

The classification of where an experiment runs, such as development, staging, or production, which drives how strict the blast-radius and approval controls must be.

A required human or automated authorization step before an experiment can run in a sensitive environment, ensuring the right people accept the risk.

The stored record of past experiment runs, including targets, faults, probe results, and outcomes, used for auditing, trend analysis, and demonstrating resilience improvements.

The spare capacity a system has beyond current load; experiments reveal whether losing instances or nodes still leaves enough headroom to serve traffic.

A Kubernetes check that determines whether a container is ready to receive traffic, which experiments exercise by killing or stressing pods to verify routing behavior.