> 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/new-to-chaos-engineering/quickstart.md).
# Quickstart
Use this guide to set up and run your first chaos experiment on target infrastructure.
### Before you begin
Review these resources and requirements:
* [Key concepts](/resilience-testing/chaos-engineering/new-to-chaos-engineering/key-concepts.md): Understand chaos engineering concepts.
* [What's supported](/resilience-testing/chaos-engineering/new-to-chaos-engineering/whats-supported.md): Confirm supported platforms and capabilities.
* **Target infrastructure**: Access a Kubernetes cluster, Linux machine, or cloud environment.
You need the following:
* **Harness account**: [Sign up](https://app.harness.io/auth/#/signup) if you do not have one.
* **Target infrastructure**: Use a Kubernetes cluster with `kubectl` access or a Linux machine with administrator privileges.
* **Permissions**: Get administrator access to install chaos agents.
### Access Harness Chaos Engineering
To access Harness Chaos Engineering:
1. [Sign up](https://app.harness.io) or log in to your Harness account.
2. In the left navigation, navigate to the **Chaos Engineering** module.
3. Create a project or ask your administrator to add you to an existing project.
### Create an environment
A chaos experiment is executed in an infrastructure that is associated with an **environment**.
To create an environment:
1. Navigate to **Environments**, then click **New Environment**.
2. Enter the environment name, description, and tags.
3. Select **Production** or **Non-Production**.
4. Click **Create**.
{% hint style="info" %}
Select an existing environment from the list when one is available.
{% endhint %}
### Set up chaos infrastructure
After you create an environment, add infrastructure to it.
#### Kubernetes
To add Kubernetes infrastructure:
1. In your environment, click **New Infrastructure**.
2. Select **Kubernetes**.
3. Select an installation mode:
* **Cluster-wide access**: Target resources across all namespaces.
* **Specific namespace access**: Restrict chaos injection to a namespace.
4. Copy and run the installation command in your cluster:
```bash
# Example installation command (use the one provided in UI)
kubectl apply -f https://app.harness.io/chaos/delegate/manifest/...
```
5. Wait until the infrastructure shows the **CONNECTED** status.
#### Linux
To add Linux infrastructure:
1. Click **New Infrastructure**, then select **Linux**.
2. Download and install the chaos agent:
```bash
# Download the agent
curl -O https://app.harness.io/chaos/linux-agent
chmod +x linux-agent
# Install with your infrastructure ID and access key
sudo ./linux-agent --install --infra-id= --access-key=
```
### Create your first chaos experiment
Create and run your first chaos experiment. Start with **Pod Delete** because it has a small blast radius.
#### Identify your target
Identify the target for your experiment:
1. Identify the microservice that you will target.
2. For Kubernetes, select a pod from your application.
3. [Pod delete](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-delete.md): Start with this experiment.
#### Create the experiment
Create the experiment:
1. Navigate to **Chaos Experiments**, then click **New Experiment**.
2. Select **Blank Canvas** or a **Template**.
3. Configure the following fields:
* **Name**: `My First Pod Delete Experiment`
* **Description**: `Testing pod resilience`
* **Tags**: Enter tags that organize the experiment.
#### Add a chaos fault
Add and configure the chaos fault:
1. In the experiment builder, click **Add Fault**.
2. Select **Kubernetes** → **Pod** → **Pod Delete**.
3. Configure the following fields:
* **Target Pods**: Select pods or use label selectors.
* **Chaos Duration**: Enter `30` seconds.
* **Force**: Set this to `false` for graceful deletion.
#### Add resilience probes
Probes validate your hypothesis during the experiment. Add an HTTP probe:
1. Click **Add Probe**.
2. Select **HTTP Probe**.
3. Configure the following fields:
* **URL**: Enter your application endpoint.
* **Method**: Select `GET`.
* **Success Criteria**: Enter response code `200`.
* **Run Properties**: Select execution during chaos.
### Run your first experiment
Run and monitor the experiment:
1. Review the experiment configuration.
2. Save the experiment.
3. Click **Run**.
4. Monitor the following:
* The experiment timeline.
* Probe results.
* System metrics and logs.
### Analyze results
After the experiment completes, review the following:
1. **Resilience Score**: Review the overall system resilience rating.
2. **Probe Results**: Check health-check results during chaos.
3. **Timeline**: Review experiment execution phases.
4. **Logs**: Review execution logs for troubleshooting.
#### Understand results
Use these results to assess system resilience:
* **Passed probes**: Your application handled the chaos.
* **Failed probes**: Identify areas that need improvement.
* **Resilience score**: Higher scores indicate greater resilience.
### Quick onboarding options
Harness Chaos Engineering offers two onboarding methods:
#### Automated onboarding
Automated onboarding provides the following:
* **One-click setup**: Creates an environment, discovers services, and runs experiments.
* **Minimal decisions**: Harness Chaos Engineering handles most configuration.
* **Resilience scores**: View resilience scores after experiments run.
#### Guided onboarding
Guided onboarding provides the following:
* **Step-by-step guidance**: Walk through each step with options.
* **More control**: Customize each step while receiving guidance.
* **Learning focus**: Understand the process while you configure it.
To access onboarding, navigate to **Chaos Engineering** → **Overview**, then select **Select a cluster**.
### Common first experiments
Use these experiments to begin resilience testing:
#### Pod Delete for Kubernetes
**Purpose**: Test application resilience to pod failures.
* **Fault**: Pod Delete.
* **Duration**: `30` seconds.
* **Success Criteria**: The service remains available, and new pods start quickly.
#### CPU Stress for Linux and Kubernetes
**Purpose**: Test application behavior under CPU pressure.
* **Fault**: CPU Stress.
* **CPU Load**: `80%`.
* **Duration**: two minutes.
* **Success Criteria**: Application performance degrades gracefully.
#### Network latency
**Purpose**: Validate application behavior under network delays.
* **Fault**: Network Latency.
* **Latency**: `100ms`.
* **Duration**: one minute.
* **Success Criteria**: Timeouts are handled gracefully.
### Next steps
You have run your first chaos experiment. Use these resources next:
* [Chaos faults](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/chaos-faults-reference.md): Try different types of chaos faults.
* [Probes](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/index.md): Configure monitoring.
* [GameDays](/resilience-testing/chaos-engineering/use-chaos-engineering/gamedays.md): Organize chaos engineering events.
* [CI/CD integration](/resilience-testing/chaos-engineering/integrations/cicd/jenkins.md): Automate chaos testing in pipelines.
{% hint style="info" %}
Next step
Build more resilient systems through systematic chaos engineering practices.
{% endhint %}