> 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/disaster-recovery-testing/pipeline-stage-reference.md).

# Pipeline Stage Reference

Field reference for DR test creation, Disaster Recovery stage tabs, Chaos Probe, Chaos Fault, Chaos Action, and Rollback.

Complete field reference for Disaster Recovery (DR) test pipelines, from the DR tests list through each Pipeline Studio tab to the results of a run. For a step-by-step walkthrough, go to [Get Started with DR Testing](/resilience-testing/disaster-recovery-testing/get-started.md).

{% hint style="info" %}
**FEATURE FLAG**

DR Testing is behind a feature flag (`CHAOS_DR_TESTING_ENABLED`). Contact your Harness sales representative to enable it for your account.
{% endhint %}

***

## DR tests list <a href="#dr-tests-list" id="dr-tests-list"></a>

Go to **Resilience Testing** > **DR Tests**. The list shows pipelines that contain at least one Disaster Recovery stage.

| Column                | Description                                                |
| --------------------- | ---------------------------------------------------------- |
| **Pipeline name**     | Display name and auto-generated identifier.                |
| **DR test stages**    | Names of the `DRTest` stages in the pipeline.              |
| **Recent executions** | Sparkline of recent run statuses.                          |
| **Last execution**    | Status and timestamp of the most recent run, or **Never**. |
| **Last modified**     | Timestamp and user who last saved the pipeline.            |

Filterable by **Search** and **Tag(s)**. Default sort: **Last Modified (New -> Old)**.

![The DR Tests list](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-5f7c1ef0cfe54f3b7480a44fb652aed51dadb8f7%2Fdr-tests-list.png?alt=media)

***

## Create new DR test dialog <a href="#create-new-dr-test-dialog" id="create-new-dr-test-dialog"></a>

Shown when you click **+ New DR Test**. **Description** and **Tags** are collapsed to a label and a pencil icon until you select the pencil.

![The Create new DR Test dialog](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-305f2d076b87bb83442078f02f3cdd121bbe2743%2Fdr-create-dialog.png?alt=media)

| Field           | Required       | Description                                                                                               |
| --------------- | -------------- | --------------------------------------------------------------------------------------------------------- |
| **Name**        | Yes            | Display name for the Disaster Recovery stage. Also used to derive the pipeline name (`<Name> Pipeline`).  |
| **Id**          | Auto-generated | Unique identifier derived from the name. Editable via the pencil icon. Must be unique within the project. |
| **Description** | No             | Free-text description of the disaster scenario.                                                           |
| **Tags**        | No             | Key or `key:value` labels for organizing and filtering.                                                   |
| **Objective**   | No             | Goal or success criteria for this DR test.                                                                |

Select **Continue in Pipeline Studio** to create the pipeline and open it. Select **Cancel** to discard the dialog without creating anything.

Harness creates:

* A pipeline with identifier derived from the name and tag `module: drtest`.
* A stage of type `DRTest` whose name and identifier match the dialog values.
* An empty Execution canvas, so you add Chaos Probe, Chaos Fault, Chaos Action, and other steps yourself.

***

## Overview tab

The stage overview is pre-populated from the create dialog. All fields remain editable.

### Stage overview fields <a href="#stage-overview-fields" id="stage-overview-fields"></a>

| Field           | Description                                         |
| --------------- | --------------------------------------------------- |
| **Name**        | Stage display name.                                 |
| **Id**          | Stage identifier. Auto-derived from name, editable. |
| **Description** | Optional stage description.                         |
| **Tags**        | Optional labels.                                    |
| **Objective**   | Optional objective for this disaster recovery test. |

### Advanced section (within overview) <a href="#advanced-section-within-overview" id="advanced-section-within-overview"></a>

| Field               | Description                                                                                                                   |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Timeout**         | Maximum allowed runtime for the stage. Accepts duration format: `w`, `d`, `h`, `m`, `s`. Example: `2h 30m`.                   |
| **Stage Variables** | Key-value variables scoped to this stage. Select **+ New Variable** to add. Reference them in steps with Harness expressions. |

***

## Execution tab

The Execution tab has two canvases, toggled with **Execution | Rollback**:

* **Execution:** The forward recovery workflow.
* **Rollback:** Compensating steps for when a failure strategy selects **Rollback Pipeline**. Harness does not enter this path automatically on probe failure unless your failure strategy invokes rollback.

Select **Add Step**, then choose **Add Step**, **Add Step Group**, **Use template**, or **Create with AI**.

In the **Step Library**, open **Resilience Testing** to add Load Test, Chaos Fault, Chaos Probe, Chaos Action, or Chaos Experiment. Open **Approval** to add Harness Approval or other approval steps. An empty Disaster Recovery stage can be saved; approval, fault, and probe steps are available but not required by schema validation before save.

![The Resilience Testing group in the Step Library](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-024f1c052668840e821e8069b0f738c03c7483dc%2Fdr-step-library.png?alt=media)

### Chaos probe <a href="#chaos-probe" id="chaos-probe"></a>

Validates a condition against your system for a configured duration.

| Field                        | Required         | Description                                                                                                                                                   |
| ---------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**                     | Yes              | Display name for the step.                                                                                                                                    |
| **Id**                       | Auto-generated   | Step identifier.                                                                                                                                              |
| **Description**              | No               | Optional step description. Collapsed behind a pencil icon.                                                                                                    |
| **Resilience Test Probe**    | Yes              | The probe identity to run, such as an HTTP or Kubernetes health probe from your project. The picker reads `Select a Probe`.                                   |
| **Select RT Infrastructure** | Yes              | Target infrastructure in the form `<environment>/<infrastructure>`.                                                                                           |
| **Duration**                 | Yes              | How long the probe runs (for example `1m`, `10m`). Placeholder text shows examples such as `10s`, `1m`, `1h`.                                                 |
| **Select Chaos Service**     | No               | Attributes the probe result to an onboarded resilience testing service. Go to [Services](/resilience-testing/shared-capabilities/services.md) to onboard one. |
| **Runtime Inputs**           | Depends on probe | Name and value pairs the selected probe exposes. Required inputs are marked. Pin a field to supply the value at run time.                                     |

The drawer for this step is titled **Resilience Test Probe**, even though the Step Library card reads **Chaos Probe**.

![The Chaos Probe step drawer](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-c98441c16b084933b3de6b1f79e636360910bb94%2Fdr-chaos-probe-step.png?alt=media)

YAML shape:

```yaml
- step:
    type: ChaosProbe
    name: ChaosProbe_1
    identifier: ChaosProbe_1
    spec:
      identity: ad-http-test-1
      duration: 10m
      infraReference: env91x/infra91xadvanced
      tasks:
        - identifier: ad-http-test-1
          values:
            - name: VARIABLES_URL
              value: https://example.com
```

### Chaos fault <a href="#chaos-fault" id="chaos-fault"></a>

Injects a failure into the target system.

| Field                        | Required         | Description                                                                                                         |
| ---------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Name**                     | Yes              | Display name for the step.                                                                                          |
| **Id**                       | Auto-generated   | Step identifier.                                                                                                    |
| **Description**              | No               | Optional step description. Collapsed behind a pencil icon.                                                          |
| **Chaos Fault**              | Yes              | Fault identity to inject. This can be a project fault or a template-backed identity such as `custom.<template-id>`. |
| **Select RT Infrastructure** | Yes              | Target infrastructure in the form `<environment>/<infrastructure>`.                                                 |
| **Runtime Inputs**           | Depends on fault | Inputs the selected fault exposes. Pin fields you want prompted at run time.                                        |

Unlike the probe and action steps, Chaos Fault takes no **Duration** field; the fault definition carries its own. It also has no **Chaos Service** field.

YAML shape:

```yaml
- step:
    type: ChaosFault
    name: ChaosFault_1
    identifier: ChaosFault_1
    spec:
      identity: custom.template-scope-test-eps
      infraReference: env91x/infra91xadvanced
```

### Chaos action <a href="#chaos-action" id="chaos-action"></a>

Runs a predefined chaos action from Resilience Testing.

| Field                        | Required          | Description                                                                                       |
| ---------------------------- | ----------------- | ------------------------------------------------------------------------------------------------- |
| **Name**                     | Yes               | Display name for the step.                                                                        |
| **Id**                       | Auto-generated    | Step identifier.                                                                                  |
| **Description**              | No                | Optional step description. Collapsed behind a pencil icon.                                        |
| **Resilience Test Action**   | Yes               | The action identity to run. The picker reads `Select an Action`.                                  |
| **Select RT Infrastructure** | Yes               | Target infrastructure in the form `<environment>/<infrastructure>`.                               |
| **Duration**                 | Yes               | How long the action runs.                                                                         |
| **Runtime Inputs**           | Depends on action | Inputs the selected action exposes, such as `VARIABLES_DURATION`. Pin fields for runtime prompts. |

The drawer for this step is titled **Resilience Test Action**, even though the Step Library card reads **Chaos Action**.

YAML shape:

```yaml
- step:
    type: ChaosAction
    name: ChaosAction_1
    identifier: ChaosAction_1
    spec:
      identity: k8s-delay-variable
      duration: 10s
      infraReference: env91x/infra91xadvanced
      tasks:
        - identifier: k8s-delay-variable
          values:
            - name: VARIABLES_DURATION
              value: 10s
```

You can also add standard Harness steps (shell script, HTTP, Harness Approval, notification) in the same stage.

### Use templates and save as template <a href="#use-templates-and-save-as-template" id="use-templates-and-save-as-template"></a>

The step menu offers two template actions:

* **Use template:** From the Add Step menu, opens **Step and Step Group Templates**. Select a template to insert it into the Execution (or Rollback) canvas. Template-backed faults often appear as an `identity` such as `custom.<template-id>` in YAML.
* **Save as Template:** On a Chaos Probe, Chaos Fault, or Chaos Action drawer, saves the current step configuration as a reusable template.

### Variables <a href="#variables" id="variables"></a>

Open **Variables** in Pipeline Studio to manage:

* **Pipeline** variables (name, identifier, tags, custom variables).
* **Stage** variables for the Disaster Recovery stage (**Add Variable** under Stage Variables).

Reference them from step inputs with Harness expressions such as `<+stage.variables.myVar>`.

***

## Advanced tab

### Delegate selector <a href="#delegate-selector" id="delegate-selector"></a>

| Field                        | Description                                                                                                                |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Define Delegate Selector** | Optional. Add selector tags to route this stage to a specific Harness Delegate. Leave empty to use any available Delegate. |

### Conditional execution <a href="#conditional-execution" id="conditional-execution"></a>

| Option                                                 | Description                                                   |
| ------------------------------------------------------ | ------------------------------------------------------------- |
| If the pipeline executes successfully up to this point | Default. Stage runs only if preceding stages passed.          |
| If the previous pipeline or stage fails                | Stage runs only if the immediately preceding stage failed.    |
| Always                                                 | Stage always runs.                                            |
| JEXL Condition                                         | Stage runs only if the custom expression evaluates to `true`. |

### Loop strategy <a href="#looping-strategy" id="looping-strategy"></a>

| Strategy        | Description                                                                 |
| --------------- | --------------------------------------------------------------------------- |
| **Matrix**      | Run the stage for each combination of values across variable axes.          |
| **Repeat**      | Run the stage a fixed number of times, optionally with a concurrency limit. |
| **Parallelism** | Split stage iterations to run in parallel up to a configured maximum.       |

### Failure strategy <a href="#failure-strategy" id="failure-strategy"></a>

Defines how the pipeline responds when the stage encounters an error. This is the only place a Disaster Recovery stage configures failure handling. Select **Add** to define a strategy; you can add several, each matching different error types.

**On failure of type.** Select one or more failure types, or check **All Errors**:

| Failure type                         | Description                                             |
| ------------------------------------ | ------------------------------------------------------- |
| Authentication Errors                | Invalid or expired credentials.                         |
| Connectivity Errors                  | Network or connectivity issues reaching a target.       |
| Timeout Errors                       | Operations that exceed their configured timeout.        |
| Authorization Errors                 | Insufficient permissions.                               |
| Verification Failures                | Step or probe verification conditions not met.          |
| Delegate Provisioning Errors         | Failures provisioning or connecting a Harness Delegate. |
| Unknown Errors                       | Errors that do not match any other category.            |
| Policy Evaluation Failures           | Governance policy checks that fail.                     |
| Execution-time Inputs Timeout Errors | Runtime input prompts that were not fulfilled in time.  |
| Approval Rejection                   | An approval step was explicitly rejected.               |
| Delegate Restart                     | The Delegate restarted during execution.                |
| User Marked Failure                  | A step was manually marked as failed.                   |

**Perform Action.** Select what Harness does when a matching failure occurs:

| Action                          | Description                                                   |
| ------------------------------- | ------------------------------------------------------------- |
| **Manual Intervention**         | Pause and wait for a user to choose the next action.          |
| **Ignore Failure**              | Treat the failure as a warning and continue.                  |
| **Retry Step**                  | Retry the failed step a configured number of times.           |
| **Mark As Success**             | Override the failure and mark the step or stage as succeeded. |
| **Abort**                       | Stop execution immediately.                                   |
| **Proceed with Default Values** | Continue using default values for unresolved inputs.          |
| **Mark As Failure**             | Mark the step or stage as failed.                             |
| **Rollback Pipeline**           | Roll back all stages in the pipeline that support rollback.   |

***

## Review probe results after a run

On a pipeline execution, open **Resilience Tests**. The tab lists Resilience Testing steps from the selected stage and reports **Probe Results** for probe outcomes.

* Use it to review probe pass or fail results after a DR run.
* For Chaos Fault and Chaos Action detail, use step **Details**, **Step Logs**, and **Console View**. The tab is not a fault catalog.

***

## Troubleshooting

<details>

<summary>A DR test pipeline does not run its rollback steps when a probe fails</summary>

Harness enters the **Rollback** canvas only when a failure strategy invokes rollback. On the stage **Advanced** tab, add a failure strategy and set **Perform Action** to **Rollback Pipeline**. A Disaster Recovery stage does not offer **Rollback Stage**.

</details>

<details>

<summary>The Add button under Failure Strategy is disabled</summary>

Harness disables **Add** while an existing strategy has errors. Finish the current strategy first: select at least one failure type under **On failure of type** and an action under **Perform Action**, then add the next one.

</details>

***

## Related concepts

The following pages cover related tasks:

* Go to [Get Started with DR Testing](/resilience-testing/disaster-recovery-testing/get-started.md) to create and run your first DR test.
* Go to [Concepts](/resilience-testing/disaster-recovery-testing/concepts.md) to understand RTO, RPO, and failure strategies.

{% @harness-feedback/feedback %}
