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 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.<name> }}
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

1. Select Submit.

In YAML, inputs are defined under pipeline.inputs. Reference them in steps using ${{ inputs.<name> }}:

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 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:

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 to learn how to manage delegates and their tags.

A delegate set at the pipeline level applies to steps that do not have their own delegate setting. A step-level delegate takes precedence.

---

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

1. Select a notification channel and configure it:

Channel	uses value	Required with fields
Email	email	recipients: [[e-mail]]
Slack	slack	url: <webhook-url>
PagerDuty	pager-duty	key: <integration-key>
Microsoft Teams	ms-teams	url: <incoming-webhook-url>
Webhook	webhook	url: <webhook-url>

1. Select Submit.

In YAML, notifications are defined under pipeline.notifications:

pipeline:
  notifications:
    - on:
        - pipeline:
            - start
            - failed
      uses: email
      with:
        recipients:
          - [e-mail]

    - 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:

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 <number><unit> 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:

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 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:

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.

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.

---

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:

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:

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:
          - [e-mail]
  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 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 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

Concurrency limits are account-wide, not per-pipeline.

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 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 to create and reuse saved input configurations.

• Go to Pipeline Studio to build and edit pipelines.

• Go to YAML reference to see how all settings map to pipeline YAML keys.

• Go to Default Settings to view all account-level pipeline settings.