Q2 2026 Product Update: Harness Pipeline | Harness Blog

Q2 | May – July 2026‍

Companion post: [Q2 26 CD & GitOps update →]

‍

Q2 2026 advances Harness Pipeline with DAG-based execution, smarter looping strategies, enhanced governance tooling, and a wave of improvements in reliability and developer experience. The quarter's headline feature — DAG pipelines — fundamentally changes how you model complex multi-stage workflows by letting stages declare explicit dependencies rather than relying on sequential order. Combined with improved cron scheduling, template label management, and a new pipeline dry-run API, Q2 gives teams greater control over how their pipelines are structured and validated. See the [Q1 2026 Pipeline update] for prior context.

‍

---

‍

Pipeline Execution

‍

DAG Pipelines (Beta)

‍

Harness now supports Directed Acyclic Graph (DAG) pipelines, enabling you to define explicit dependencies between stages instead of relying on sequential or parallel stage order. Each stage declares the stages it must complete before it starts via the dependsOn field, so independent execution paths progress as soon as their dependencies finish — without waiting for unrelated stages to complete. This unlocks execution patterns that are common in CI but historically difficult to model in CD: fan-out/fan-in topologies, diamond-shaped dependency graphs, and multi-path workflows where different service groups deploy in parallel but converge on a shared integration step.

Learn more about DAG pipelines →

‍

Pipeline Chaining with Looping Strategies

‍

Pipeline chaining now supports looping strategies when a parent pipeline calls a child pipeline, so you can run a child pipeline multiple times across a matrix or repeat configuration. Previously, chaining was limited to a single child pipeline invocation per stage. Teams that deploy to multiple environments or regions by parameterizing a shared child pipeline can now drive those invocations directly from the parent's looping strategy rather than duplicating stages.

‍Learn more about pipeline chaining →

‍

Matrix Exclusions Evaluated at Loop Start

‍

Matrix looping strategies now evaluate and exclude conditions at the beginning of the loop, removing excluded combinations before iterations start, rather than skipping them mid-execution. This change eliminates "skipped" iterations from cluttering your execution view and makes matrix execution counts predictable — the number of running iterations you see matches the number that will actually do work. 

Learn more about matrix looping strategies →

‍

Barrier Cycle Detection

‍

Harness now detects barrier reference cycles and enforces unique barrier references within a stage or step group, preventing circular barrier dependencies that could deadlock a pipeline. Pipelines with cycle configurations will fail validation at save time rather than silently deadlocking at runtime — a much faster feedback loop for teams using barriers to synchronize parallel deployments.

Learn more about barriers →

‍

Cron Triggers with AND Semantics

‍

Cron triggers now support AND semantics for complex scheduling where both a date range and a day-of-week condition must be satisfied simultaneously. For example, 0 3 16-22 * 1 executes at 3:00 AM UTC only on Mondays between the 16th and 22nd of the month. This enables precise scheduling for monthly maintenance windows, release cycles, and compliance-driven deployment schedules without scripting workarounds. 

Learn more about cron triggers →

‍

Governance & Policy

‍

Harness AI for OPA Policies

‍

OPA policy authoring now uses the unified Harness AI agent for enhanced, context-aware policy generation. Powered by specialized skills trained on OPA and REGO best practices, the AI assistant helps you write policies without deep REGO knowledge and generates plain-language descriptions of existing policies. Teams can iterate on governance rules faster, with less reliance on REGO specialists.

Learn more about building policies with Harness AI →

‍

OPA Enforcement on Git-Backed Entities

‍

Harness now runs onSave OPA policies when you commit changes to a Git-backed entity directly in Git, and blocks pipeline execution when the most recent commit fails the policy check. Previously, changes committed directly to Git bypassed onSave policy evaluation entirely — meaning governance rules that would have blocked a save in the Harness UI could be circumvented by editing the YAML in Git. With this feature enabled, Harness uses a GitX webhook to detect commits, evaluates the new version against applicable onSave policy sets, and tracks both the Last Commit and the Last Valid Commit for each entity. A validation badge in Pipeline Studio and Template Studio shows the evaluation result, and the Run Pipeline flow blocks execution with the same policy results modal rather than a generic error. To unblock a pipeline whose latest commit fails policy, fix the entity in Git and commit again — Harness re-evaluates on the new commit. 

Learn more about enforcing policies on Git-backed entities →

‍

Policy as Code: 6-Month Evaluation Data Retention

‍

Harness now retains Policy as Code evaluation data for 6 months by default. If your account has a pipeline data retention policy that exceeds 6 months, your OPA evaluations retention automatically aligns with the longer window. You can download evaluation data for compliance purposes or request a custom retention period. This closes a gap for compliance teams that needed evaluation history for audit trails beyond short-term retention windows. 

Learn more about policy evaluations retention →

‍

Policy as Code: Cloud Storage for Evaluation Inputs

‍

Large OPA evaluation inputs (pipeline YAML, Terraform plans, IaCM stacks) are now stored in cloud storage (GCS/S3) rather than the database, optimizing database performance for accounts with high evaluation volumes. Evaluation results and metadata remain in the database for fast access. A new signed URL API endpoint (GET /api/v1/evaluations/evaluation-input-signed-url/{id}) lets you retrieve input data from cloud storage when needed. 

Learn more about how evaluation data is stored →

‍

Executions Management Page

‍

A new Executions Management page gives you account-level visibility into all queued and running pipeline executions. You can see queue positions, monitor execution status across organizations and projects, and abort individual or bulk executions from Account Settings > Security and Governance > Executions Management. This is the operational view platform teams have needed for managing execution backlogs and diagnosing concurrency issues without diving into individual project views.

Learn more about Executions Management →

‍

Templates & Input Sets

‍

Template Overrides

‍

Templates now support configurable overrides, letting template owners designate specific advanced settings that callers can override without editing or duplicating the template. The template owner marks settings as overridable in the template's allowedOverrides list — including conditional execution, failure strategy, looping strategy, delegate selectors, and policy enforcement — and each caller that references the template can supply its own value for any allowed setting via templateOverrides in YAML. Any setting not listed in allowedOverrides remains locked to the template's value. A common use case: a stage template used across 50 pipelines sets a default conditional execution rule, and a single pipeline that needs different behavior overrides just that one setting instead of maintaining a duplicate template. Supported for step, stage, step group, and pipeline templates. 

Learn more about template overrides →

‍

Template Labels

‍

Harness now supports template labels for referencing template versions using semantic names instead of fixed version numbers. Labels let you create stable, human-readable pointers like stable, latest, or team-approved that you update as your template evolves, so pipelines that reference a label automatically pick up new template versions without requiring each pipeline to be updated. 

Learn more about template labels →

‍

Pipeline Dry Run Validation API

‍

A new dry run validation API endpoint lets you validate pipeline YAML changes while editing files in Git before committing them to your repository. The endpoint performs YAML schema validation, template expansion, and OPA policy evaluation without executing the pipeline — providing the same validation feedback you get from the Harness UI editor to Git-native workflows and CI checks. Available at POST /pipeline/api/v1/orgs/{org}/projects/{project}/dry-run. 

Learn more about pipeline YAML validation →

‍

Tag Filtering with AND/OR Logic

‍

Pipeline execution filtering by tags now supports AND/OR logic, enabling Matches Any (OR) or Matches All (AND) filtering. Teams using tags to label executions by environment, team, or release train can now run more expressive queries across their execution history without filtering results manually after fetching.

‍

Git Experience

‍

Git Tags for Pipeline and Input Set Sources

‍

Pipeline YAML and input sets stored in Git can now be referenced using Git tags in addition to branch names during trigger-based executions. Use the $tag:<tag-name> format in the Pipeline Reference Branch or Input Set Source fields (for example, $tag:v1.0.0), or resolve tag names dynamically from trigger expressions. This enables version-controlled pipeline configurations that align with your release workflow — triggering on a Git tag runs the pipeline and input set version that matches that tag, making rollbacks to prior configurations as simple as re-running against the original tag. Requires delegate version 26.04.89002 or later. Learn more about Git tag support →

‍

Git Experience Monitoring & Observability

‍

A new Webhooks monitoring section gives you full visibility into the health of your Git Experience. The Events tab shows the complete history of webhook events processed by Harness, with per-event payloads and troubleshooting details for synchronization failures. The new Observability tab goes further — it surfaces repository synchronization health across all Git-backed repositories (showing webhook coverage and sync status at a glance) and tracks Git provider API rate-limit consumption per connector, so you can identify which connectors are approaching rate limits before they cause sync failures. 

Learn more about monitoring Git Experience →

‍

Input Set Caching

‍

The Harness Git cache now extends to remote input sets, joining remote pipelines and templates. Input sets stored in Git are cached and served from the cache in the UI, reducing load times when opening or editing input sets for large repositories. A new refresh-and-get API endpoint lets you programmatically clear and refresh the cache for a specific branch, returning the refreshed entity in a single call — the API equivalent of the Reload from Git UI action. 

Learn more about Git caching →

‍

Git-Based Pipeline YAML in Dynamic Stages

‍

Harness now supports Git-based pipeline YAMLs in Dynamic Stages, allowing you to execute pipeline YAMLs stored in Git repositories in addition to inline and runtime-provided YAML. You can optionally specify a commit hash to pin execution to a specific version of the file — useful for audit trails and reproducible pipeline runs.

‍

Notifications & Observability

‍

Multi-Line String Variables

‍

String variables at pipeline and stage scope now support a multi-line input mode. With this feature enabled, any variable marked as multi-line expands to a resizable text area wherever users are prompted for that variable's value — in the run pipeline dialog, in input sets, and in the pipeline editor. This removes the friction of editing long structured values like YAML configuration blocks, lists of IP addresses, or shell script snippets through a single-line input. Learn more about variables →

‍

"Waiting for User Action" Pipeline Notification Event

‍

Harness now fires a "Waiting for User Action" notification event whenever a pipeline pauses for user input— such as Approval steps, Manual Interventions, or runtime input requests. You can configure these notifications at both the pipeline level and through centralized notification rules, enabling on-call routing, Slack alerts, or webhook integrations that fire precisely when a human action is blocking a deployment. 

Learn more about pipeline notifications →

‍

What's Next

‍

Q3 FY27 will continue expanding pipeline execution models, deepen template and Git Experience integrations, and bring further improvements to the governance and observability layer. Explore the Harness Developer Hub for full documentation.

‍