Feature Requests

Description / Problem Statement Currently, Harness rollout deployments for Kubernetes do not provide sufficient visibility into pod-level status during the deployment process. Customers need more granular information to understand why pods are failing, which significantly impacts their ability to debug and resolve deployment issues efficiently. Requested Features Pod Status Visibility: Real-time display of individual pod status within a rollout deployment. Kubernetes Rollout Status Monitoring: Native monitoring of Kubernetes rollout progress and state transitions. Pod Health Metrics: Visibility into readiness and liveness probe statuses for each pod. Container Log Access: Direct access to container logs for failed or unhealthy pods to diagnose issues such as: CrashLoopBackOff, Image pull failures, Health check failures, Configuration issues, Runtime exceptions during deployment Use Case / Impact This enhancement would allow DevOps and platform engineering teams to quickly identify and remediate deployment failures without needing to switch to external kubectl or monitoring tools. It reduces MTTR (Mean Time To Resolution) for failed deployments and improves the overall deployment experience within Harness.

When executing Command or Shell Script steps on a remote host via SSH, Harness uses the default shell of the target machine and its internal wrapper script assumes Bash syntax. If the remote host's default shell is tcsh or csh, both the wrapper and user scripts fail with unclear errors ("Command not found", "Undefined variable"). Shebangs do not override this behavior. Request: Add support for non-Bash shells (tcsh, csh, ksh) on remote SSH targets, or invoke Bash explicitly regardless of the host's default shell. If a target shell is unsupported, fail with a clear error message stating the shell is not supported rather than producing misleading errors.

We're trying to use the AWS Pod Identity association feature in AWS EKS, but it doesn't seem to be working. Could you please enable support for this feature?

Currently, Harness does not support “Move to Git” for triggers, unlike pipelines, templates, and input sets. This limits full GitOps adoption. Without Git versioning, trigger management becomes manual, error-prone, and lacks auditability. It also creates inconsistency across environments. Request: Enable triggers to be managed via Git (YAML), including version control, sync, and promotion across environments—aligned with other entities.

I would like Dark Mode so my eyes don't scorch when using the UI late at night

For traceability we would like to inject labels to kubernetes entities generated via helm deployments. We would like to be able to source the labels from harness variables or tags at the project, service, environment and pipeline level. E.g. buildversion : <+pipeline.variables.buildVersion>

Requesting support for version-controlled CI/CD pipeline triggers and input sets, including the ability to select and manage specific versions during pipeline execution. In particular, pipeline triggers should support Git-backed/versioned storage so that trigger definitions can be stored, reviewed, and managed directly from GitHub alongside pipeline code. Current Limitation Currently: Pipelines themselves can be versioned and managed through Git experience. Triggers and input sets are not fully version-aware in the same way. Changes to triggers/input sets can overwrite previous configurations without clear version history or rollback capability. Trigger configurations are not easily reviewable through standard Git workflows (PR review, audit trail, revert, branch-specific behavior, etc.). This creates operational challenges when managing multiple environments, release workflows, or evolving CI/CD logic. Requested Enhancement: Versioned Pipeline Triggers Support versioning of CI/CD triggers with: Git-backed storage of trigger YAML/configuration Ability to save trigger definitions in GitHub repositories PR review workflow for trigger changes Version history and rollback support Branch-aware trigger configurations Ability to select or pin a specific trigger version Versioned Input Sets Support versioning for input sets with: Full version history Ability to select specific input set versions during execution Rollback capability Git-backed configuration support Environment/release-specific input set management Version Selection at Runtime Allow users to: Select which version of a trigger or input set should be used Associate trigger versions with specific pipeline versions Promote validated configurations across environments

Description: Currently, Harness does not support “Move to Git” for triggers, unlike pipelines, templates, and input sets. This limits full GitOps adoption. Without Git versioning, trigger management becomes manual, error-prone, and lacks auditability. It also creates inconsistency across environments. Request: Enable triggers to be managed via Git (YAML), including version control, sync, and promotion across environments—aligned with other entities.

We have a weird stage where we need to pause the Pipeline and redirect users to our internal platform UI. I'd like to be able to set a message that everyone can use. It's pretty much saying what the stage does and a link to my own UI for them to provide an attestation/approval so I can track it. support to display a message and a HTTP URL when the pipeline is in waiting in approval state for the users who are non-approvers when they view pipeline execution.

We are requesting a native integration between Harness and Azure DevOps (ADO) Boards to automatically create work items for pipeline failures. Currently, we attempted to use Harness → ServiceNow integration for incident management, but we faced a major limitation in our operating model: Applications are supported by multiple PODs (teams) ServiceNow requires a single assignment group at ticket creation Harness does not have sufficient context to dynamically determine the correct assignment group This results in: Incorrect incident routing Manual reassignment efforts Increased MTTR and reduced operational efficiency To address this, we are moving toward using ADO Boards for failure tracking, where: Work items can be mapped to area paths / teams Ownership can be aligned more accurately with POD-based support models