> 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/harness-platform/3.0/harness-platform-resources/overview/pipeline-settings.md). # Pipeline settings Configure per-pipeline settings including inputs, delegate, notifications, clone behavior, timeout duration, selective stage execution, and rerun behavior. Per-pipeline settings are accessible from the **Configure pipeline** panel in Pipeline Studio. Open it by selecting the **⚙** (gear) icon in the top-right corner of the canvas. The panel contains: **Inputs**, **Delegate**, **Notifications**, **Clone**, **Timeout duration**, **Allow Selective stage execution**, and **Is input data uneditable when rerunning?** Select **Submit** at the bottom of the panel to apply changes. Go to [Account-level pipeline settings](#account-level-pipeline-settings) to view concurrency limits and execution limits. ## What you will learn * How to define pipeline inputs, set delegates, and configure notifications * How to control clone behavior and set pipeline timeout duration * How to enable selective stage execution and lock inputs on rerun * What account-level settings govern concurrency limits, trigger behavior, and timeout caps *** ## Inputs Pipeline inputs are typed parameters collected when the pipeline is triggered manually or via API. Inputs let you reuse a single pipeline definition for different scenarios: supply a different image version, target environment, or feature flag value at runtime. **To add an input:** 1. In the Configure pipeline panel, select **+ Add** under **Inputs**. 2. Configure the input: | Field | Description | | --------------- | -------------------------------------------------------------------------------- | | **Name** | The input identifier, referenced in the pipeline as `${{ inputs. }}` | | **Type** | Data type: `string`, `number`, `boolean`, `secret`, `environment`, or `duration` | | **Default** | Value used when none is provided at runtime | | **Description** | Label shown in the run form | | **Required** | Whether a value must be supplied before running | 3. Select **Submit**. In YAML, inputs are defined under `pipeline.inputs`. Reference them in steps using `${{ inputs. }}`: ```yaml pipeline: inputs: version: type: string default: "1.0.0" desc: Image tag to deploy required: false source-repo: type: string required: true stages: - id: build name: build runtime: cloud steps: - id: print name: Print version run: script: echo "Deploying ${{ inputs.version }} from ${{ inputs.source-repo }}" ``` Go to [Input sets and overlays](/harness-platform/3.0/harness-platform-resources/overview/input-sets.md) to create and manage saved input configurations. *** ## Delegate The delegate setting controls which Harness Delegate executes the pipeline. By default, Harness selects an available delegate automatically. Specify a delegate name or tag to route execution to a specific delegate, for example, one in a particular network zone or with specific tooling installed. **To set a delegate:** 1. In the Configure pipeline panel, select **+ Add** under **Delegate**. 2. Enter a delegate name or tag. To target multiple delegates, add multiple entries; Harness selects one that matches. 3. Select **Submit**. In YAML, use `pipeline.delegate`. Pass a single value or a list: ```yaml pipeline: # Single delegate delegate: my-delegate # Or multiple delegate tags (Harness picks one that matches) delegate: - delegate-tag-1 - delegate-tag-2 ``` Delegate tags are defined on the delegate itself. Go to [Delegates](/harness-platform/3.0/harness-platform-resources/delegates.md) to learn how to manage delegates and their tags. {% hint style="info" %} A delegate set at the pipeline level applies to steps that do not have their own delegate setting. A step-level delegate takes precedence. {% endhint %} *** ## Notifications Notification settings send alerts when specific pipeline events occur, such as when the pipeline starts, fails, or succeeds. **To add a notification rule:** 1. In the Configure pipeline panel, select **+ Add** under **Notifications**. 2. Select the events that trigger the notification: | Event | YAML value | | --------------------------- | ------------------- | | Pipeline starts | `pipeline: start` | | Pipeline succeeds | `pipeline: success` | | Pipeline fails | `pipeline: failed` | | Pipeline ends (any outcome) | `pipeline: end` | | Stage starts | `stage: start` | | Stage succeeds | `stage: success` | | Stage fails | `stage: failed` | | Step fails | `step: failed` | | Trigger fails | `trigger: failed` | 3. Select a notification channel and configure it: | Channel | `uses` value | Required `with` fields | | --------------- | ------------ | -------------------------------- | | Email | `email` | `recipients: [user@example.com]` | | Slack | `slack` | `url: ` | | PagerDuty | `pager-duty` | `key: ` | | Microsoft Teams | `ms-teams` | `url: ` | | Webhook | `webhook` | `url: ` | 4. Select **Submit**. In YAML, notifications are defined under `pipeline.notifications`: ```yaml pipeline: notifications: - on: - pipeline: - start - failed uses: email with: recipients: - user@example.com - on: - pipeline: - failed - stage: - failed uses: slack with: url: https://hooks.slack.com/services/your-webhook ``` *** ## Clone Clone settings configure how Harness checks out your source repository when the pipeline runs. The **Clone** dropdown controls whether cloning is enabled. Select **Advanced** to expand additional clone options. | Setting | YAML field | Description | | -------------------------- | ------------ | ------------------------------------------------------------------------------------ | | **Clone** (enable/disable) | `enabled` | `true` to clone, `false` to skip | | **Repository** | `repo` | Repository name or URL to clone | | **Depth** | `depth` | Number of commits to fetch. `1` for a shallow clone (faster); omit for a full clone. | | **Strategy** | `strategy` | `source-branch` clones the source branch; `merge` merges it into the target first | | **Submodules** | `submodules` | Whether to clone Git submodules | | **LFS** | `lfs` | Whether to fetch Git LFS files | | **Tags** | `tags` | Whether to fetch tags | In YAML, clone settings are defined under `pipeline.clone`: ```yaml pipeline: # Disable cloning entirely clone: enabled: false # Enable cloning with advanced options clone: enabled: true repo: my-repo depth: 1 strategy: source-branch submodules: false lfs: false tags: false ``` *** ## Timeout duration The timeout sets the maximum time the pipeline is allowed to run before Harness terminates it and marks it as failed. Enter a duration using `` format: for example, `30m`, `2h`, or `1d`. The field supports expressions. Select the **{}** button to reference a pipeline variable as the timeout value. In YAML, set timeout under `pipeline.timeout`: ```yaml pipeline: timeout: 30m ``` Timeouts can also be set at the stage and step level. The most restrictive timeout in the hierarchy is enforced: 1. Account-level timeout (cannot be exceeded) 2. Organization-level timeout 3. Project-level timeout 4. Pipeline timeout (set here) 5. Stage timeout 6. Step timeout Go to [Account-level pipeline settings](#pipeline-timeout-and-stage-timeout) to review timeout limits per plan tier. *** ## Allow selective stage execution When enabled, you can choose which stages to run when triggering the pipeline manually, instead of running all stages in sequence. This is useful for large pipelines where you want to re-run only a specific portion or skip stages during development. In YAML, set `allow-stage-executions` under the pipeline: ```yaml pipeline: allow-stage-executions: true ``` When enabled, the **Run Pipeline** form shows a stage selector so you can include or exclude individual stages before executing. {% hint style="warning" %} Skipping a stage means its outputs and artifacts are not produced. Ensure downstream stages do not depend on anything a skipped stage would have created. {% endhint %} *** ## Is input data uneditable when rerunning? When enabled, pipeline inputs are locked to their original values when you rerun an execution. You cannot change the input values during a rerun; the pipeline uses exactly the same inputs as the original run. In YAML, set `fixed-inputs-on-rerun` under the pipeline: ```yaml pipeline: fixed-inputs-on-rerun: true ``` Use this when auditability or reproducibility is important and you want to prevent input drift between the original run and a rerun. *** ## All settings together The following shows all per-pipeline settings in a single YAML: ```yaml pipeline: id: my-pipeline name: My Pipeline inputs: version: type: string default: "1.0.0" desc: Image tag to deploy required: false source-repo: type: string required: true delegate: my-delegate notifications: - on: - pipeline: - start uses: email with: recipients: - user@example.com clone: enabled: true repo: my-repo depth: 1 strategy: source-branch submodules: false lfs: false tags: false timeout: 30m allow-stage-executions: true fixed-inputs-on-rerun: true stages: - id: build name: build runtime: cloud platform: os: linux arch: amd64 steps: - id: run name: Run run: script: echo "Hello from ${{ inputs.source-repo }}" ``` *** ## Account-level pipeline settings Account administrators configure default limits and behaviors in **Account Settings > General > Default Settings > Pipeline**. Most settings have an **Allow Override** checkbox that controls whether lower scopes (org, project) can change the value. ### Trigger settings | Setting | Default | Description | | --------------------------------------------------------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Webhook Polling For Triggers** | False | Enables polling-based webhook trigger detection instead of relying on push events from the SCM. | | **Mandate pipeline create and edit permission to create and edit triggers** | True | When enabled, users must have Pipeline: Create/Edit permission to create or edit triggers for a pipeline. When disabled, trigger permission alone is sufficient. | | **Mandate Authorization for Custom Webhook Triggers** | False | Requires all custom webhook triggers to use an API key token for authentication. Go to [Enforcing authorization for custom triggers](/harness-platform/3.0/harness-platform-resources/triggers/trigger-deployments-using-custom-triggers.md) to configure this. | | **Mandate Webhook Secrets for Github Triggers** | False | Forces all GitHub webhook triggers to use a secret for authentication. The repository webhook must be configured with the same secret after creating the trigger in Harness. | | **Execute Triggers With All Collected Artifacts or Manifests** | False | When enabled, all artifacts or manifests collected during a polling interval trigger a deployment, one per artifact/manifest collected. Go to [Trigger pipelines on a new artifact](/harness-platform/3.0/harness-platform-resources/triggers/trigger-on-a-new-artifact.md) to understand this behavior. | ### Execution settings | Setting | Default | Description | | ------------------------------------------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Enable Pipeline Execution Audit Events** | False | By default, pipeline execution events (Pipeline Start, Pipeline End, Stage Start, Stage End) are not shown in the Audit Trail. Enable to include them. | | **Run RBAC Validation before executing Inline Pipelines** | True | Before running a pipeline, Harness checks whether the user has access to all environments and resources the pipeline will access. Applies to inline pipelines only. Disable if the check is not required, but note that pipelines may fail mid-execution if later stages have permission issues. | | **Do Not Delete Pipeline Execution Details** | False | When True, execution history is retained even after the pipeline is deleted. Retained executions are viewable but cannot be re-run. Execution data is still subject to the standard Harness data retention policy. | | **Allow users to mark a running Step as failure** | True | Allows users to manually mark an in-progress step as failed without waiting for it to time out or finish. | | **Run Pre Flight checks by Default for Pipeline Executions** | False | Runs pre-execution governance and policy checks before a pipeline starts. When enabled, policy violations block execution before any stage runs. | | **Allow Dynamic Executions for Pipelines** | True | Enables dynamic execution mode, which allows pipeline inputs and configurations to be modified dynamically at execution time. | | **Allow using original pipeline YAML for reruns** | False | When True, reruns use the pipeline YAML from the original execution rather than the current saved version. Useful for reproducibility when the pipeline definition has changed since the original run. | ### Concurrent active pipeline executions Harness limits how many pipeline executions can run simultaneously per account. Executions that exceed the limit are queued and start automatically when capacity is available. | Plan Tier | Default | Maximum | | ------------------------------------ | ------- | --------------- | | Free plan and Team/Enterprise trials | 2 | 2 | | Team plan | 200 | 500 | | DevOps Essentials | 60 | Contact Support | | Enterprise plan | 500 | 1000 | | Essentials (Flex Pricing) | 500 | 1000 | {% hint style="warning" %} Concurrency limits are account-wide, not per-pipeline. {% endhint %} ### Pipeline timeout and stage timeout Account-level timeouts cap the maximum timeout any pipeline or stage can set. Individual pipelines and stages cannot exceed the account-level limit even if configured with a longer value. | Plan Tier | Pipeline timeout | Stage timeout | | ---------------------- | ---------------- | ------------- | | Free plan | 2 hours | 1 hour | | Team/Enterprise trials | 4 hours | 1 hour | | Team plan | 30 days | 30 days | | Enterprise plan | 35 days | 35 days | ### CI and CD settings | Setting | Default | Description | | ----------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Export Service Variables as Env Variables** | False | Exports Harness service variables as environment variables in Shell Script steps. | | **Enable Matrix Labels By Name** | False | Uses the names of matrix axes as stage labels instead of index-based labels (\_1\_2, \_2\_2, etc.). | | **Enable Json Support for expressions** | False | Allows writing expressions using any JSON parser tool. Go to [Write expressions using JSON](/harness-platform/3.0/harness-platform-resources/variables-and-expressions/expression-v2.md#write-expressions-using-json) to use a JSON parser in expressions. | | **Default Image Pull Policy For Add On Container** | Always | Sets the image pull policy for internal Harness images that run inside a pod alongside your containers. Options: `Always`, `Never`, `IfNotPresent`. | | **Default Image Pull Policy Set to Empty By Default** | Empty | Sets the add-on container image pull policy to empty (unset), letting the container runtime apply its own default. Takes effect when no explicit pull policy is configured. | ### Parallelism limit The maximum number of parallel stages or steps at any level in a pipeline is a fixed limit that cannot be changed: * Free plan and Team/Enterprise trials: 10 * Team plan and Enterprise plan: 256 Pipelines that define more parallel items than this limit cannot be executed. Even if `max-parallel` is set lower, Harness evaluates the total number of potential stages at plan creation time; if the total exceeds the plan limit, the execution fails before any stage runs. ## Next steps * Go to [Input sets and overlays](/harness-platform/3.0/harness-platform-resources/overview/input-sets.md) to create and reuse saved input configurations. * Go to [Pipeline Studio](/harness-platform/3.0/harness-platform-resources/overview/pipeline-studio.md) to build and edit pipelines. * Go to [YAML reference](/harness-platform/3.0/harness-platform-resources/overview/yaml-reference.md) to see how all settings map to pipeline YAML keys. * Go to [Default Settings](/harness-platform/3.0/harness-platform-resources/settings.md) to view all account-level pipeline settings.