> 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.md).

# Faults

- [Chaos Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-faults.md): Comprehensive library of pre-built chaos faults for testing system resilience
- [Chaos Fault Categories](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories.md)
- [Chaos Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/chaos-faults-reference.md): Comprehensive library of pre-built chaos faults for testing system resilience
- [AWS](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws.md)
- [Requirements](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/permissions.md): Requirements to fulfill before executing AWS chaos experiments.
- [Common AWS fault tunables](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/aws-fault-tunables.md)
- [Security configurations](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/security-configurations.md)
- [Introduction](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/security-configurations/introduction.md): Introduction to security configuration
- [AWS secret-based authentication](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/security-configurations/aws-switch-profile.md): Manage different users to perform AWS API calls
- [Policy for all AWS faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/security-configurations/policy-for-all-aws-faults.md): AWS superset policy to execute all AWS faults
- [Use IAM roles for authentication](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/security-configurations/aws-iam-integration.md)
- [IRSA (OIDC Method)](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/security-configurations/aws-iam-integration/irsa-oidc-method-aws-iam-integration.md)
- [AWS Assume Role Method](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/security-configurations/aws-iam-integration/aws-assume-role-method-aws-iam-integration.md)
- [EC2-backed and serverless faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-and-serverless-faults.md)
- [ALB AZ down](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/alb-az-down.md): Detach one or more availability zones from an Application Load Balancer for a configurable duration so you can test how clients, target groups, and AZ-aware routing behave when a zone is taken out of
- [Chaos faults for AWS](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/aws.md)
- [AZ blackhole](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/az-blackhole.md): Isolate network traffic for one or more AWS Availability Zones (optionally scoped to specific VPCs or subnets) for a configurable duration and restore connectivity afterwards so you can test how multi
- [CLB AZ down](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/clb-az-down.md): Disable one or more availability zones on a Classic Load Balancer for a configurable duration so you can test how clients and back-end instances behave when an AZ is removed from the load balancer rot
- [DynamoDB replication pause](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/dynamodb-replication-pause.md): Pause cross-region replication on one or more Amazon DynamoDB global tables for a configurable duration using an AWS Fault Injection Service (FIS) experiment so you can test how your application handl
- [EBS loss by ID](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ebs-loss-by-id.md): Detach an EBS volume by volume ID for a configurable duration and reattach it afterwards so you can test how a workload behaves when its storage disappears.
- [EBS loss by tag](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ebs-loss-by-tag.md): Detach EBS volumes selected by tag for a configurable duration and reattach them afterwards so you can test how workloads behave when a tagged subset of storage disappears.
- [EC2 CPU hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-cpu-hog.md): Stress a configurable number of CPU cores inside a target EC2 instance via AWS Systems Manager so you can test how the workload behaves when the host is starved of CPU.
- [EC2 DNS chaos](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-dns-chaos.md): Block or redirect DNS resolution for selected hostnames on a target EC2 instance via AWS Systems Manager so you can test how the workload reacts when a dependency cannot be resolved.
- [EC2 HTTP latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-latency.md): Add latency to inbound HTTP traffic on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react when an HTTP service responds slowly.
- [EC2 HTTP modify body](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-modify-body.md): Replace HTTP response bodies on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react when an upstream returns unexpected content.
- [EC2 HTTP modify header](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-modify-header.md): Add, change, or remove HTTP headers on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react when headers are missing or malformed.
- [EC2 HTTP reset peer](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-reset-peer.md): Reset TCP connections to an HTTP service on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react when the server tears down connections mid-flight.
- [EC2 HTTP status code](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-http-status-code.md): Rewrite HTTP response status codes on a configurable port of a target EC2 instance via AWS Systems Manager so you can test how clients react to specific error codes returned by an upstream service.
- [EC2 IO stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-io-stress.md): Generate sustained filesystem read and write load on a target EC2 instance via AWS Systems Manager so you can test how the workload behaves under disk pressure or near-full storage.
- [EC2 memory hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-memory-hog.md): Consume a configurable amount of memory inside a target EC2 instance via AWS Systems Manager so you can test how the workload behaves when the host is starved of memory.
- [EC2 network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-network-latency.md): Add configurable latency and jitter to outbound traffic on an EC2 instance via AWS Systems Manager so you can test how the workload reacts when network round-trip times grow.
- [EC2 network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-network-loss.md): Drop a configurable percentage of outbound packets on a target EC2 instance via AWS Systems Manager so you can test how the workload reacts when network reliability degrades.
- [EC2 process kill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-process-kill.md): Kill one or more processes by PID inside a target EC2 instance via AWS Systems Manager, so you can test how the workload recovers when a critical process disappears without losing the host.
- [EC2 stop by ID](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-stop-by-id.md): Stop one or more EC2 instances selected by instance ID for a configurable duration so you can test how the workload running on those instances behaves during and after the outage.
- [EC2 stop by tag](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ec2-stop-by-tag.md): Stop EC2 instances selected by tag for a configurable duration so you can test how the workload running on those instances behaves when a tagged subset disappears.
- [ECS agent stop](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-agent-stop.md): Stop the ECS container agent on every container instance in an ECS cluster for a configurable duration so you can test how tasks, scheduling, and self-healing behave when the cluster temporarily loses
- [ECS container CPU hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-cpu-hog.md): Stress a configurable number of CPU cores at a configurable load percentage inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how the workload beha
- [ECS container HTTP latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-http-latency.md): Add latency to inbound HTTP traffic on a specific port inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how clients behave when the HTTP service r
- [ECS container HTTP modify body](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-http-modify-body.md): Replace HTTP response bodies on a specific port inside a percentage of running ECS tasks (EC2 launch type) with a configurable string for a configurable duration so you can test how clients behave whe
- [ECS container HTTP reset peer](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-http-reset-peer.md): Reset TCP connections to HTTP clients on a specific port after a configurable timeout inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how clients
- [ECS container HTTP status code](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-http-status-code.md): Return a configurable HTTP status code (and optionally rewrite the body) on a specific port inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how c
- [ECS container IO stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-io-stress.md): Stress filesystem IO using a configurable number of workers writing to a configurable mount path inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test
- [ECS container memory hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-memory-hog.md): Consume a configurable amount of memory (absolute or percentage) using a configurable number of workers inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you ca
- [ECS container network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-network-latency.md): Add a configurable amount of network latency on a specific interface inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how the workload behaves whe
- [ECS container network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-network-loss.md): Drop a configurable percentage of network packets on a specific interface inside a percentage of running ECS tasks (EC2 launch type) for a configurable duration so you can test how the workload behave
- [ECS container volume detach](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-container-volume-detach.md): Detach the data volume attached to a percentage of running ECS tasks for a configurable duration so you can test how the workload behaves when its storage disappears.
- [ECS Fargate CPU hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-fargate-cpu-hog.md): Inject CPU stress inside a percentage of running ECS Fargate tasks for a configurable duration via a sidecar container so you can test how the service behaves under sustained CPU pressure.
- [ECS Fargate memory hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-fargate-memory-hog.md): Consume a configurable amount of memory inside a percentage of running ECS Fargate tasks for a configurable duration via a sidecar container so you can test how the service behaves under sustained mem
- [ECS instance stop](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-instance-stop.md): Stop one or more EC2 container instances that back an ECS cluster for a configurable duration so you can test how the cluster reschedules tasks, drains workloads, and recovers when capacity disappears
- [ECS invalid container image](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-invalid-container-image.md): Swap the container image of an ECS service to an invalid value for a configurable duration so you can test how ECS, your deployment guardrails, and your alerting respond to a failed image pull.
- [ECS network restrict](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-network-restrict.md): Add or remove a network rule (ingress or egress, by IP and port range) for the security group of one or more ECS services for a configurable duration so you can test how the workload behaves when netw
- [ECS task scale](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-task-scale.md): Force one or more ECS services to a configurable replica count for a configurable duration so you can test how the workload, dependent services, and autoscaling logic behave when capacity is suddenly
- [ECS task stop](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-task-stop.md): Stop a configurable percentage of ECS tasks (selected by task ID or by service) for a configurable duration so you can test how the service reschedules, how dependent traffic reroutes, and how the wor
- [ECS update container resource limit](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-update-container-resource-limit.md): Re-register the task definition of an ECS service with smaller CPU and memory limits for a configurable duration so you can test how the workload behaves when its container resources shrink.
- [ECS update container timeout](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-update-container-timeout.md): Re-register the task definition of an ECS service with chaos values for container start and stop timeouts for a configurable duration so you can test how the workload behaves when ECS no longer waits
- [ECS update task role](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ecs-update-task-role.md): Swap the task role of an ECS service to a chaos value (or empty) for a configurable duration so you can test how the workload behaves when its IAM identity loses or changes permissions.
- [Generic FIS experiment template](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/generic-experiment-template.md): Trigger any pre-built AWS Fault Injection Service (FIS) experiment template by ID from Harness Chaos Engineering so you can fold native AWS-managed faults into your chaos experiments and probe / verif
- [Lambda block TCP connection](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-block-tcp-connection.md): Block outbound TCP connections from an AWS Lambda function to one or more target hostnames for a configurable duration so you can test how the function behaves when a TCP-based dependency is unreachab
- [Lambda delete event source mapping](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-delete-event-source-mapping.md): Delete one or more event source mappings on an AWS Lambda function for a configurable duration and recreate them afterwards so you can test how the workload behaves when the function stops receiving e
- [Lambda delete function concurrency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-delete-function-concurrency.md): Delete the reserved concurrency configuration on an AWS Lambda function for a configurable duration and restore it afterwards so you can test how the workload behaves when the function has to share ac
- [Lambda function layer detach](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-function-layer-detach.md): Detach a specified Lambda layer from a target AWS Lambda function for a configurable duration and reattach it afterwards so you can test how the workload behaves when a shared dependency layer disappe
- [Lambda inject latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-inject-latency.md): Inject runtime latency into an AWS Lambda function for a configurable duration so you can test how upstream callers and downstream consumers handle slower-than-expected responses, cold-start spikes, a
- [Lambda inject status code](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-inject-status-code.md): Override the HTTP status code returned by an AWS Lambda function for a configurable duration so you can test how upstream callers and downstream consumers handle unexpected error status responses.
- [Lambda modify response body](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-modify-response-body.md): Override the response body returned by an AWS Lambda function for a configurable duration so you can test how upstream callers and client applications handle unexpected payload shapes and corrupted da
- [Lambda toggle event mapping state](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-toggle-event-mapping-state.md): Disable one or more event source mappings on an AWS Lambda function for a configurable duration and re-enable them afterwards so you can test how the workload behaves when the function temporarily sto
- [Lambda update function memory](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-update-function-memory.md): Lower the memory allocation of an AWS Lambda function for a configurable duration and restore it afterwards so you can test how the workload behaves with less memory and a proportionally smaller CPU s
- [Lambda update function timeout](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-update-function-timeout.md): Lower the configured timeout of an AWS Lambda function for a configurable duration and restore it afterwards so you can test how the workload behaves when invocations are cut short.
- [Lambda update role permission](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/lambda-update-role-permission.md): Detach a specified IAM policy from the execution role attached to an AWS Lambda function for a configurable duration and reattach it afterwards so you can test how the workload behaves when the functi
- [NLB AZ down](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/nlb-az-down.md): Detach one or more availability zones from a Network Load Balancer for a configurable duration so you can test how clients, target groups, and AZ-aware routing behave when a zone is taken out of the l
- [RDS instance delete](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/rds-instance-delete.md): Delete a target RDS DB instance so you can test how applications behave when a database disappears permanently and how disaster-recovery procedures handle the loss.
- [RDS instance reboot](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/rds-instance-reboot.md): Reboot a target RDS DB instance (with optional Multi-AZ failover) for a configurable duration so you can test how applications behave when their database restarts.
- [Resource access restrict](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/resource-access-restrict.md): Temporarily strip ingress or egress rules from one or more AWS security groups for a configurable duration and restore them afterwards so you can test how the workload behaves when network access to (
- [SSM chaos by ID](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ssm-chaos-by-id.md): Run an arbitrary AWS Systems Manager document against a target EC2 instance selected by ID so you can inject custom chaos that is not covered by a dedicated fault.
- [SSM chaos by tag](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/ssm-chaos-by-tag.md): Run an arbitrary AWS Systems Manager document against EC2 instances selected by tag so you can inject custom chaos against a logical group of hosts.
- [VPC route misconfiguration](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/vpc-route-misconfiguration.md): Temporarily remove specified CIDR routes from one or more VPC route tables for a configurable duration and restore them afterwards so you can test how the workload behaves when egress to a Transit Gat
- [Windows EC2 blackhole chaos](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-blackhole-chaos.md): Blackhole all network traffic destined for specific IPs or hosts on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads b
- [Windows EC2 CPU hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-cpu-hog.md): Stress a configurable number of CPU cores at a configurable percentage on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workl
- [Windows EC2 memory hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-memory-hog.md): Consume a configurable amount of memory (absolute or percentage) on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads b
- [Windows EC2 network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-network-latency.md): Add a configurable amount of latency to network traffic destined for specific IPs or hosts on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how
- [Windows EC2 network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-network-loss.md): Drop a configurable percentage of network packets destined for specific IPs or hosts on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Window
- [Windows EC2 process kill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/aws/windows-ec2-process-kill.md): Kill one or more processes (selected by PID or process name) on one or more Windows EC2 instances (selected by ID or tag) for a configurable duration so you can test how Windows-hosted workloads behav
- [Common Tunables for All Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/common-tunables-for-all-faults.md): Configuration parameters shared across all chaos faults
- [Azure](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure.md)
- [Security configurations](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/security-configurations.md)
- [Required Permissions and Custom Roles For Azure Chaos Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/security-configurations/fault-permissions.md)
- [Azure authentication methods for chaos faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/security-configurations/azure-authentication-methods.md)
- [Azure AKS node down](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-aks-node-down.md): Deallocate a percentage of AKS worker VMs (selected by node pool and zone) for a configurable duration so you can test how the workload behaves when AKS nodes disappear.
- [Azure disk loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-disk-loss.md): Detach one or more managed data disks from an Azure VM for a configurable duration, then reattach them, so you can test how the workload behaves when its storage disappears.
- [Azure instance CPU hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-instance-cpu-hog.md): Drive CPU utilization to a configurable target on one or more Azure VMs for a configurable duration so you can test how the workload behaves when compute headroom shrinks.
- [Azure instance IO stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-instance-io-stress.md): Drive disk IO load on one or more Azure VMs for a configurable duration so you can test how the workload behaves when the storage subsystem is saturated.
- [Azure instance memory hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-instance-memory-hog.md): Consume a configurable amount of memory on one or more Azure VMs for a configurable duration so you can test how the workload behaves when memory headroom shrinks.
- [Azure instance stop](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-instance-stop.md): Stop one or more Azure VM instances by name for a configurable duration, then start them again, so you can test how the workload behaves when a VM disappears.
- [Azure Service Bus queue state change](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-service-bus-queue-state-change.md): Change the operational status of one or more Azure Service Bus queues (Disabled, SendDisabled, ReceiveDisabled) for a configurable duration so you can test how producers and consumers handle queue-sta
- [Azure web app access restrict](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-web-app-access-restrict.md): Add an Access Restriction rule to one or more Azure App Service web apps for a configurable duration so you can test how clients behave when traffic to the web app is blocked.
- [Azure web app stop](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-web-app-stop.md): Stop one or more Azure App Service web apps for a configurable duration, then start them again, so you can test how clients behave when the web app is unavailable.
- [Chaos faults for Azure](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure.md)
- [Cloud Foundry](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry.md)
- [Requirements](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/permissions.md): Requirements to fulfill before executing Cloud Foundry chaos experiments.
- [CF chaos components and deployment architecture](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-components-and-arch.md): Chaos components and their deployment architecture used in CF fault injection
- [CF app container kill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-container-kill.md): Kill the container of a Cloud Foundry app instance so you can test how the platform reschedules it and how peers absorb traffic during the gap.
- [CF app JVM CPU stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-jvm-cpu-stress.md): Drive CPU saturation inside the JVM of a Cloud Foundry app instance so you can test how the application and the platform react to sustained CPU pressure.
- [CF app JVM memory stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-jvm-memory-stress.md): Drive heap or non-heap memory pressure inside the JVM of a Cloud Foundry app instance so you can test how the application reacts to sustained memory exhaustion.
- [CF app JVM method exception](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-jvm-method-exception.md): Make a specific JVM method throw an exception inside a Cloud Foundry app instance so you can test how callers handle synchronous failures.
- [CF app JVM method latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-jvm-method-latency.md): Add artificial latency to a specific JVM method inside a Cloud Foundry app instance so you can test how slow downstream calls cascade through the system.
- [CF app JVM modify return](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-jvm-modify-return.md): Override the return value of a specific JVM method inside a Cloud Foundry app instance so you can test caller behavior against unexpected return values.
- [CF app JVM trigger GC](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-jvm-trigger-gc.md): Trigger a full garbage collection cycle inside the JVM of a Cloud Foundry app instance so you can measure pause time and tail-latency impact.
- [CF app network corruption](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-network-corruption.md): Corrupt a configurable percentage of egress packets from a Cloud Foundry app instance so you can test how TCP retransmissions and protocol handlers cope.
- [CF app network duplication](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-network-duplication.md): Duplicate a configurable percentage of egress packets from a Cloud Foundry app instance so you can test deduplication logic and idempotency assumptions.
- [CF app network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-network-latency.md): Inject network latency on the egress of a Cloud Foundry app instance so you can test how the app and its callers behave when downstream calls become slow.
- [CF app network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-network-loss.md): Drop a configurable percentage of egress packets from a Cloud Foundry app instance so you can test retry, timeout, and circuit-breaker behavior.
- [CF app route unmap](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-route-unmap.md): Temporarily unmap a route from a Cloud Foundry app so you can test how upstream consumers behave when the app becomes unreachable via that route.
- [CF app stop](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cf-app-stop.md): Stop a Cloud Foundry app for a configurable duration, then restart it, so you can test how the platform and dependents react when the app goes offline.
- [Chaos faults for Cloud Foundry](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/cloud-foundry/cloud-foundry.md): Catalog of Cloud Foundry chaos faults that disrupt apps, JVM runtimes, and the network between app instances and their dependencies.
- [GCP](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp.md)
- [Security configuration](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/security-configurations.md)
- [Creating secrets for GCP experiments](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/security-configurations/prepare-secret-for-gcp.md)
- [Use IAM roles for authentication](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/security-configurations/gcp-iam-integration.md)
- [GCP SQL instance failover](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/gcp-sql-instance-failover.md): Trigger a failover on a GCP Cloud SQL high-availability instance so you can test how the application behaves when the primary node fails over to its standby.
- [GCP VM disk loss by label](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/gcp-vm-disk-loss-by-label.md): Detach a percentage of non-boot persistent disks selected by label from GCP VM instances for a configurable duration, then reattach them, so you can test how the workload behaves when a labeled subset
- [GCP VM disk loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/gcp-vm-disk-loss.md): Detach one or more non-boot persistent disks from GCP VM instances for a configurable duration, then reattach them, so you can test how the workload behaves when its storage disappears.
- [GCP VM instance stop by label](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/gcp-vm-instance-stop-by-label.md): Stop a percentage of GCP Compute Engine VM instances selected by label for a configurable duration, then start them again, so you can test how the workload behaves when a labeled subset of VMs disappe
- [GCP VM instance stop](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/gcp-vm-instance-stop.md): Stop one or more GCP Compute Engine VM instances by name for a configurable duration, then start them again, so you can test how the workload behaves when a VM disappears.
- [Chaos faults for GCP](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/gcp/gcp.md)
- [Kube Resilience](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kube-resilience.md)
- [Kubelet density](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kube-resilience/kubelet-density.md): Create a configurable number of pods on a target Kubernetes node so you can test how the node, kubelet, and workload behave during a sudden pod-storm.
- [Kubernetes](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes.md)
- [Classification of Kubernetes faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/classification.md)
- [Permissions](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/permissions.md)
- [Fault-wise permissions](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/permissions/fault-wise-permission.md)
- [Chaos agent installation access requirements](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/permissions/kubernetes-chaos-agent.md): Kubernetes chaos agent installation access requirements
- [Fault container permissions](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/permissions/container-permissions.md)
- [TKGi deployment approach and permissions](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/tkgi.md)
- [Prerequisites before executing faults on TKGi](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/tkgi/permissions.md)
- [Fault injection on Tanzu Kubernetes Grid-based infrastructure](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/tkgi/tkgi-deployment.md)
- [Comparison of EC2 Chaos Approach for Kubernetes versus Linux](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/comparison-ec2.md): Comparison of EC2 Chaos Approach for (Kubernetes + SSM) versus Native Linux agent.
- [Node](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node.md)
- [Best Practices for Probe Validation - Node Level Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/probe-validations.md)
- [Common node fault tunables](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/common-tunables-for-node-faults.md): Environment variables shared by node-level chaos faults for selecting target nodes by name, by label, or by percentage.
- [Kubelet service kill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/kubelet-service-kill.md): Stop the kubelet on a Kubernetes node to simulate node loss without rebooting, and test eviction, rescheduling, and recovery behavior.
- [Node CPU hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-cpu-hog.md): Exhaust CPU on a Kubernetes node to test scheduler behavior, pod eviction under pressure, HPA reactions, and noisy-neighbor isolation.
- [Node drain](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-drain.md): Cordon and drain a Kubernetes node using the Eviction API to test PodDisruptionBudget enforcement, graceful shutdown, and rescheduling behavior.
- [Node I/O stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-io-stress.md): Stress disk I/O on a Kubernetes node to test ephemeral-storage eviction, etcd write tolerance, log shipper backpressure, and noisy-neighbor isolation.
- [Node memory hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-memory-hog.md): Exhaust memory on a Kubernetes node to test kubelet eviction order, QoS-based pod prioritization, OOM behavior, and noisy-neighbor isolation.
- [Node network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-network-latency.md): Inject configurable network latency on a Kubernetes node's interface to test application timeouts, retry tuning, and tail-latency resilience.
- [Node network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-network-loss.md): Drop a configurable percentage of packets on a Kubernetes node's network interface to test cluster, application, and control-plane resilience.
- [Node restart](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-restart.md): Reboot a Kubernetes node over SSH to test how the cluster handles sudden node loss, pod rescheduling, and stateful recovery.
- [Node taint](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-taint.md): Apply a temporary taint to a Kubernetes node to test toleration correctness, scheduling policies, and NoExecute eviction behavior.
- [Pod](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod.md)
- [Best Practices for Probe Validation - Pod Level Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/probe-validations.md)
- [Common pod fault tunables](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/common-tunables-for-pod-faults.md)
- [Container kill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/container-kill.md): Kill a specific container inside a Kubernetes pod to test restart loops, sidecar resilience, probe tuning, and multi-container coordination.
- [Disk fill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/disk-fill.md): Fill a target Kubernetes container's ephemeral storage as a percentage of its limit to test ephemeral-storage eviction, retention, and back-pressure logic.
- [FS fill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/fs-fill.md): Write a configurable amount of data into a specific path inside a Kubernetes container to test mounted-volume capacity, eviction, and write-failure handling.
- [Pod API block](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-block.md): Block selected API requests or responses on a target Kubernetes pod using path, method, header, query parameter, and source or destination filters to test client retry and failover behavior.
- [Pod API latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-latency.md): Add a configurable delay to selected API calls on a target Kubernetes pod using path, method, header, query, and source or destination filters to test client timeouts, retries, and tail-latency budget
- [Pod API modify body](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-body.md): Overwrite API request or response bodies on a target Kubernetes pod using path, method, header, query, and source or destination filters to test client behavior under corrupted payloads.
- [Pod API modify header](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-header.md): Override API request or response headers on a target Kubernetes pod using path, method, query, and source or destination filters to test resilience to missing, altered, or unexpected header values.
- [Pod API modify response custom](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-response-custom.md): Combine status code, header, and body modifications on selected API calls of a target Kubernetes pod in a single fault, with filtering by path, method, query, source, or destination.
- [Pod API status code](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-status-code.md): Override the HTTP status code returned by selected API calls on a target Kubernetes pod using path, method, header, query, and source or destination filters to test client error handling and circuit-b
- [Pod application function error](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-application-function-error.md): Inject a configurable error into a specific function of an instrumented application running in a Kubernetes pod so you can test how callers and dependents handle the failure.
- [Pod application function exception](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-application-function-exception.md): Throw a configurable exception from a specific function of an instrumented application running in a Kubernetes pod so you can test how callers and dependents handle the failure.
- [Pod application function latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-application-function-latency.md): Add a configurable delay to a specific function of an instrumented application running in a Kubernetes pod so you can test timeout, retry, and tail-latency behavior of callers.
- [Pod autoscaler](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-autoscaler.md): Scale a Kubernetes workload's replicas up to a target count to test cluster capacity, node autoscaling, scheduling pressure, and rollback behavior.
- [Pod CPU hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-cpu-hog.md): Consume CPU on a target Kubernetes pod's container to test autoscaling, throttling, latency budgets, and noisy-neighbor tolerance.
- [Pod delete](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-delete.md): Delete one or more pods of a Kubernetes workload to test replica availability, controller recovery, graceful termination, and disruption budgets.
- [Pod DNS error](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-dns-error.md): Block DNS resolution for selected hostnames inside a target Kubernetes pod to test how the application handles upstream lookup failures and cluster DNS outages.
- [Pod DNS spoof](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-dns-spoof.md): Redirect DNS lookups for selected hostnames inside a target Kubernetes pod to a different address to test how the application handles misdirected upstream traffic and cache poisoning.
- [Pod HTTP latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-latency.md): Add a configurable delay to HTTP responses served by a target Kubernetes pod to test timeouts, retries, and tail-latency behavior at the application protocol layer.
- [Pod HTTP modify body](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-modify-body.md): Overwrite the HTTP response body returned by a target Kubernetes pod to test client behavior under corrupted, empty, or unexpected response payloads.
- [Pod HTTP modify header](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-modify-header.md): Override HTTP request or response headers served by a target Kubernetes pod to test client and server resilience to missing, altered, or unexpected header values.
- [Pod HTTP reset peer](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-reset-peer.md): Forcibly reset TCP connections carrying HTTP requests to a target Kubernetes pod to test client retry, connection-pool, and circuit-breaker behavior on abrupt disconnects.
- [Pod HTTP status code](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-status-code.md): Override the HTTP response status code returned by a target Kubernetes pod to test client error handling, retry classification, and circuit-breaker behavior on specific HTTP status codes.
- [Pod IO attribute override](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-attribute-override.md): Override file attributes (such as permissions, size, or ownership) returned by stat syscalls on a target Kubernetes pod's mounted volume to test how the application reacts to changed metadata.
- [Pod IO error](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-error.md): Make filesystem syscalls on a target Kubernetes pod's mounted volume return a configurable error code, so you can validate how the application handles failed reads, writes, and opens.
- [Pod IO latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-latency.md): Add configurable delay to filesystem syscalls against a target Kubernetes pod's mounted volume so you can test how the application behaves under slow storage.
- [Pod IO mistake](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-mistake.md): Seed wrong data into reads or writes against a target Kubernetes pod's mounted volume so you can validate how the application detects and recovers from silent data corruption.
- [Pod IO stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-stress.md): Generate sustained filesystem read and write load inside a target Kubernetes pod to test how the application handles disk pressure, slow IO, and ephemeral storage exhaustion.
- [Pod JVM CPU stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-cpu-stress.md): Generate sustained CPU load inside a JVM running in a target Kubernetes pod to test how the application behaves when its Java process is starved of CPU.
- [Pod JVM Kafka exception](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-kafka-exception.md): Cause Kafka producer or consumer calls from a JVM running in a target Kubernetes pod to throw a configurable exception on a chosen topic so you can test caller error handling.
- [Pod JVM Kafka latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-kafka-latency.md): Add a configurable delay to Kafka producer or consumer calls from a JVM running in a target Kubernetes pod, scoped by topic, so you can test timeout, back-pressure, and lag behavior under slow Kafka t
- [Pod JVM memory stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-memory-stress.md)
- [Pod JVM method exception](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-method-exception.md): Cause a specific Java method in a JVM running in a target Kubernetes pod to throw a configurable exception so you can test how callers handle the failure.
- [Pod JVM method latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-method-latency.md): Add a configurable delay to every invocation of a specific Java method in a JVM running in a target Kubernetes pod so you can test how callers and dependents behave under slow methods.
- [Pod JVM modify return](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-modify-return.md): Override the return value of a specific Java method in a JVM running in a target Kubernetes pod so you can test how callers behave when a method silently returns wrong data.
- [Pod JVM Mongo exception](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-mongo-exception.md): Cause MongoDB operations from a JVM running in a target Kubernetes pod to throw a configurable exception on a chosen database, collection, and operation so you can test caller error handling.
- [Pod JVM Mongo latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-mongo-latency.md): Add a configurable delay to MongoDB operations from a JVM running in a target Kubernetes pod, scoped by database, collection, and operation, so you can test timeout and back-pressure behavior under a
- [Pod JVM Solace exception](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-solace-exception.md): Cause Solace publisher or subscriber calls from a JVM running in a target Kubernetes pod to throw a configurable exception on a chosen topic or queue so you can test caller error handling.
- [Pod JVM Solace latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-solace-latency.md): Add a configurable delay to Solace publisher or subscriber calls from a JVM running in a target Kubernetes pod, scoped by topic or queue, so you can test timeout and back-pressure behavior under slow
- [Pod JVM SQL exception](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-sql-exception.md): Cause JDBC calls from a JVM running in a target Kubernetes pod to throw a configurable exception on a chosen table and SQL operation so you can test caller error handling.
- [Pod JVM SQL latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-sql-latency.md): Add a configurable delay to JDBC calls from a JVM running in a target Kubernetes pod, scoped by table and SQL operation, so you can test timeout and back-pressure behavior under a slow database.
- [Pod JVM trigger GC](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-trigger-gc.md): Force the JVM in a target Kubernetes pod to run garbage collection on a configurable schedule so you can test how the application behaves under repeated GC pauses.
- [Pod memory hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-memory-hog.md): Consume memory inside a target Kubernetes pod's container to test OOM behavior, eviction order, request handling under pressure, and limit enforcement.
- [Pod network corruption](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-corruption.md): Corrupt a configurable percentage of packets on a target Kubernetes pod's network namespace to test checksum, retransmit, and integrity behavior.
- [Pod network duplication](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-duplication.md): Duplicate a configurable percentage of packets on a target Kubernetes pod's network namespace to test idempotency and dedup behavior.
- [Pod network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-latency.md): Add a configurable delay to packets on a target Kubernetes pod's network path to test timeout, retry, and tail-latency behavior of upstream and downstream calls.
- [Pod network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-loss.md): Drop a configurable percentage of packets on a target Kubernetes pod's network path to test retry, timeout, and failover behavior.
- [Pod network partition](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-partition.md): Apply a temporary Kubernetes NetworkPolicy to isolate a target pod from its peers, dependencies, or namespaces and test split-brain behavior.
- [Pod network rate limit](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-rate-limit.md): Cap bandwidth on a target Kubernetes pod's network path to test throughput-sensitive workloads, batch jobs, and bandwidth-bound flows.
- [Redis cache expire](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-expire.md): Expire one or more keys (or all keys) in a target Redis instance for a configurable duration so you can test how the application behaves when its cache is suddenly evicted.
- [Redis cache limit](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-limit.md): Cap the maximum memory of a target Redis instance to force evictions and write errors so you can test how the application behaves when Redis runs out of memory.
- [Redis cache penetration](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-penetration.md): Generate a configurable burst of cache-miss requests against a target Redis instance so you can test how the application and its downstream database behave when the cache is bypassed.
- [Time chaos](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/time-chaos.md): Shift the wall-clock time observed by selected processes inside a target Kubernetes pod to test application behavior under clock skew, token expiry, and time-based scheduling errors.
- [Chaos Faults for Kubernetes](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/kubernetes.md)
- [Linux](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux.md)
- [Requirements](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/permissions.md): Requirements to fulfill before executing chaos experiments on Linux OS.
- [Linux API block](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-block.md): Block API requests passing through a target Linux machine for a configurable duration by returning a configured status code, so you can test how callers handle a sudden API outage.
- [Linux API latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-latency.md): Add latency to API requests passing through a target Linux machine for a configurable duration so you can test how callers handle slow API responses.
- [Linux API modify body](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-modify-body.md): Replace API request or response bodies passing through a target Linux machine for a configurable duration so you can test how callers handle unexpected payloads.
- [Linux API modify header](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-modify-header.md): Override HTTP headers on API requests or responses passing through a target Linux machine for a configurable duration so you can test how callers handle altered headers.
- [Linux API status code](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-status-code.md): Override the HTTP status code (and optionally the response body) of API responses passing through a target Linux machine for a configurable duration.
- [Linux CPU stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-cpu-stress.md): Apply CPU load to a target Linux machine for a configurable duration so you can test how the workload behaves when compute is starved.
- [Linux disk fill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-disk-fill.md): Fill a disk path on a target Linux machine to a configured size for a configurable duration so you can test how the workload behaves when storage runs out.
- [Linux disk I/O stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-disk-io-stress.md): Apply disk I/O load to a target Linux machine for a configurable duration so you can test how the workload behaves when disk bandwidth is saturated.
- [Linux DNS error](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-dns-error.md): Force DNS resolution failures for target host names on a Linux machine for a configurable duration so you can test how the workload behaves during a DNS outage.
- [Linux DNS spoof](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-dns-spoof.md): Return spoofed IP addresses for target host names on a Linux machine for a configurable duration so you can test how the workload behaves when DNS resolves to unexpected endpoints.
- [Linux fs fill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-fs-fill.md): Fill a filesystem path on a target Linux machine to a configured size for a configurable duration so you can test how the workload behaves when storage runs out.
- [Linux JVM CPU stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-cpu-stress.md): Apply CPU stress inside a target Java process on a Linux machine for a configurable duration so you can test how the JVM behaves under compute pressure.
- [Linux JVM memory stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-memory-stress.md): Apply memory stress inside a target Java process on a Linux machine for a configurable duration so you can test how the JVM behaves under memory pressure.
- [Linux JVM method exception](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-method-exception.md): Throw a configured exception from a target class and method in a Java process on a Linux machine so you can test how the application handles unexpected exceptions.
- [Linux JVM method latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-method-latency.md): Add latency to a target class and method in a Java process on a Linux machine so you can test how the application behaves when an internal method slows down.
- [Linux JVM modify return](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-modify-return.md): Override the return value of a target class and method in a Java process on a Linux machine so you can test how callers handle unexpected return data.
- [Linux JVM trigger GC](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-trigger-gc.md): Force garbage collection in a target Java process on a Linux machine for a configurable duration so you can test how the workload behaves under repeated GC events.
- [Linux memory stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-memory-stress.md): Consume memory on a target Linux machine for a configurable duration so you can test how the workload behaves under memory pressure and OOM conditions.
- [Linux network corruption](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-corruption.md): Corrupt a percentage of network packets leaving a target Linux machine for a configurable duration so you can test how the workload behaves when packet contents are damaged.
- [Linux network duplication](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-duplication.md): Duplicate a percentage of network packets leaving a target Linux machine for a configurable duration so you can test how the workload behaves when packets are duplicated.
- [Linux network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-latency.md): Add network latency to traffic leaving a target Linux machine for a configurable duration so you can test how the workload behaves when the network is slow.
- [Linux network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-loss.md): Drop a percentage of network packets leaving a target Linux machine for a configurable duration so you can test how the workload behaves when packets are lost.
- [Linux network rate limit](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-rate-limit.md): Throttle network bandwidth leaving a target Linux machine for a configurable duration so you can test how the workload behaves when bandwidth is constrained.
- [Linux process kill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-process-kill.md): Kill target processes on a Linux machine for a configurable duration so you can test how the workload behaves when a critical process disappears.
- [Linux service restart](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-service-restart.md): Stop and restart systemd services on a target Linux machine for a configurable duration so you can test how the workload behaves when a service flaps.
- [Linux time chaos](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-time-chaos.md): Skew the system clock on a target Linux machine for a configurable duration so you can test how the workload behaves when time jumps forward or backward.
- [Chaos Faults for Linux](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux.md)
- [Load](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/load.md)
- [K6 loadgen](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/load/k6-loadgen.md): Generate a configurable load against a target endpoint with a k6 script for a configurable duration so you can test how the workload behaves under sustained traffic.
- [Chaos faults for load generation](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/load/load.md)
- [Locust loadgen](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/load/locust-loadgen.md): Generate a configurable load against a target host with a Locust script for a configurable duration so you can test how the workload behaves under sustained traffic.
- [SSH](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/ssh.md)
- [Prerequisites](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/ssh/prerequisites.md)
- [SSH chaos](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/ssh/ssh-chaos.md): Run a custom chaos script and matching abort script on a remote VM over SSH for a configurable duration so you can build any kind of host-level fault that the gold-standard fault library does not cove
- [Chaos faults for SSH](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/ssh/ssh.md)
- [VMware](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware.md)
- [Permissions Required](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/permissions.md)
- [VMware - vCenter](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/vcenter.md)
- [VMware VM power off (by name)](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/vcenter/vmware-vm-poweroff-by-name.md): Power off one or more VMware VMs (identified by name) for a configurable duration so you can test how applications behave when a VM disappears.
- [VMware VM power off (by MOID)](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/vcenter/vmware-vm-poweroff.md): Power off one or more VMware VMs (identified by Managed Object ID) for a configurable duration so you can test how applications behave when a VM disappears.
- [VMware - Linux](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux.md)
- [Prerequisites- Installing Binaries](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/binary-installation.md)
- [VMware CPU hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-cpu-hog.md): Consume CPU resources on a Linux VMware VM for a configurable duration so you can test how the workload behaves when compute headroom shrinks.
- [VMware DNS chaos](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-dns-chaos.md): Force DNS resolution failures for specific hostnames inside a Linux VMware VM so you can test how the workload behaves when DNS is unhealthy.
- [VMware HTTP latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-http-latency.md): Inject HTTP response latency on a target service running inside a Linux VMware VM so you can test how callers behave when a downstream service slows down.
- [VMware HTTP reset peer](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-http-reset-peer.md): Reset TCP connections to an HTTP service running inside a Linux VMware VM so you can test how callers behave when the service rudely drops connections.
- [VMware HTTP response modify](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-http-response-modify.md): Rewrite HTTP responses (status code, body, headers) from a service running inside a Linux VMware VM so you can test how callers behave when responses are corrupted.
- [VMware IO stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-io-stress.md): Drive disk IO load on a Linux VMware VM for a configurable duration so you can test how the workload behaves when storage throughput is saturated.
- [VMware memory hog](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-memory-hog.md): Consume a configurable amount of memory on a Linux VMware VM for a configurable duration so you can test how the workload behaves when memory headroom shrinks.
- [VMware network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-network-latency.md): Inject network latency on egress traffic from a Linux VMware VM for a configurable duration so you can test how the workload behaves under slow networks.
- [VMware network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-network-loss.md): Drop a configurable percentage of egress packets on a Linux VMware VM so you can test how the workload behaves when packet loss spikes.
- [VMware network rate limit](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-network-rate-limit.md): Cap egress bandwidth on a Linux VMware VM so you can test how the workload behaves when network throughput is throttled.
- [VMware process kill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-process-kill.md): Kill one or more processes inside a Linux VMware VM for a configurable duration so you can test how supervisors and application logic recover.
- [VMware service stop](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-service-stop.md): Stop one or more services inside a Linux VMware VM for a configurable duration so you can test how the workload behaves when a managed service is down.
- [Chaos faults for VMware](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/vmware.md)
- [Windows](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows.md)
- [Prerequisites](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/prerequisites.md)
- [Requirements and security considerations](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-chaos-permissions.md): Requirements to fulfill and security considerations to execute Windows chaos experiments.
- [Windows blackhole chaos](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-blackhole-chaos.md): Block all network traffic to selected destination hosts or IP addresses from a Windows VM so you can test how the workload behaves during a network blackout.
- [Windows CPU stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-cpu-stress.md): Consume CPU resources on a Windows VM for a configurable duration so you can test how the workload behaves when compute headroom shrinks.
- [Windows disk stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-disk-stress.md): Drive disk IO load on a Windows VM for a configurable duration so you can test how the workload behaves when storage throughput is saturated.
- [Windows memory stress](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-memory-stress.md): Consume memory on a Windows VM for a configurable duration so you can test how the workload behaves when memory headroom shrinks.
- [Windows network corruption](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-network-corruption.md): Corrupt a configurable percentage of egress packets from a Windows VM so you can test how the workload behaves when packets arrive damaged.
- [Windows network duplication](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-network-duplication.md): Duplicate a configurable percentage of egress packets from a Windows VM so you can test how the workload behaves when packets are duplicated.
- [Windows network latency](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-network-latency.md): Inject network latency on egress traffic from a Windows VM so you can test how the workload behaves when a downstream dependency slows down.
- [Windows network loss](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-network-loss.md): Drop a configurable percentage of egress packets from a Windows VM so you can test how the workload behaves when packet loss spikes.
- [Windows process kill](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-process-kill.md): Kill one or more processes on a Windows VM by PID or process name so you can test how supervisors and application logic recover.
- [Chaos faults for Windows](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows.md)
- [Chaos faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/chaos-faults.md)
- [BYOC](https://developer.harness.io/resilience-testing/chaos-engineering/faults/byoc.md)
- [Overview](https://developer.harness.io/resilience-testing/chaos-engineering/faults/byoc/byoc.md)
- [BYOC Injector](https://developer.harness.io/resilience-testing/chaos-engineering/faults/byoc/byoc-injector.md)
- [Cross-Project Cloud SQL Failover Using BYOC Injector](https://developer.harness.io/resilience-testing/chaos-engineering/faults/byoc/sql-failover.md)
- [Custom Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/custom-faults.md)
- [Overview](https://developer.harness.io/resilience-testing/chaos-engineering/faults/custom-faults/index.md): Learn how to create and implement custom chaos faults for your specific use cases
- [Create Custom Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/custom-faults/create-custom-faults.md): Learn how to create custom chaos faults from scratch with complete control over configuration
- [Custom Fault Templates](https://developer.harness.io/resilience-testing/chaos-engineering/faults/custom-faults/custom-fault-templates.md): Learn how to create custom chaos faults using pre-configured templates for faster development
- [Chaos Faults](https://developer.harness.io/resilience-testing/chaos-engineering/faults/index.md): Overview of chaos faults available in Harness Chaos Engineering