Feature Requests

We are using many layers of templates and need to set up webhooks to prevent slowness. Currently there is no way to create a webhook in Harness unless the connector set on the webhook has permission to create the webhook in our GitLab instance. Our GitLab cannot connect directly to Harness, and we do not want webhooks to stack up that will be creating errors in our GitLab instance. We will be using an intermediary service to relay the webhooks from GitLab into Harness. So the ideal solution is a toggle that will allow us to create the webhook on the Harness end, but not attempt to create the webhook inside of GitLab.

We have a requirement where we would like for GitOps pipelines to not execute if an existing execution is already running with the same inputs. We don't want queueing. We want it to just not run when matching inputs (service and env) are provided.

For some reason it seems like deployment type templates are not supported by the move to git operation. Support suggested we get an enhancement request open to get this supported. Technically there's ways to do this by modifying the YAML directly, but we would like this supported natively.

Values for privileged and allowPrivilegeEscalation on k8s build infra are not set unless enabled and disabled for the containerised step group. The user have to deliberately make the config changes to mark the privileged and allowPrivilegeEscalation as false. It should be taken as false if the config is not checkmarked at first.

Show Service with no running Active Instances in Service Page There are be apps/services that are just batch components that will not have any instances but thsi needs to be showed as deployed and shown in the services page.

Summary Request for Harness team to implement enhanced backend monitoring capabilities and improve feature flag evaluation alerting to support better troubleshooting and issue detection. Description We need improved visibility into the Harness backend system behavior and more robust alerting for feature flag evaluation issues. These improvements will enable faster troubleshooting and reduce time to resolution for production issues. Objectives Increase monitoring and observability capabilities for Harness backend changes Implement improved alerting system for feature flag evaluation issues Business Justification Current monitoring limitations make troubleshooting backend issues time-consuming and difficult Feature flag evaluation problems can impact user experience without timely detection Enhanced monitoring will reduce MTTR (Mean Time To Resolution) and improve system reliability Acceptance Criteria Enhanced Backend Monitoring: Implementation of detailed logging for backend operations Creation of customizable dashboards showing key backend metrics Addition of tracing capabilities for request flows through the system Documentation of new monitoring capabilities Feature Flag Evaluation Improvements: Real-time alerting for feature flag evaluation failures Metrics dashboard for feature flag performance and error rates Logging of feature flag evaluation context for debugging Alert threshold configuration options Additional Context Our team has experienced several incidents where troubleshooting was significantly delayed due to limited visibility into backend operations. We've also had multiple feature flag issues that were only discovered after user reports. https://docs.google.com/document/d/1HSv2ZFXYaqbybNdj6DVNmXH6J5N3jVNLwdR-fAVL4i8/edit?tab=t.0#bookmark=id.5i648mxa9xhl

As Delegates the integral piece of Harness and requires to be Highly Available, A feature to enable monitoring tied to SRM / IR can be made available such that teams can configured and raise alert if the Compute threshold are hit or Delegates go down

User require CI_CONSERVATIVE_K8_RESOURCE_LIMITS feature flag functionality for the containerised step group in Custom/CD stage for the minimum resource usage by lite-engine.

Summary: Currently, Helm charts that utilize the lookup function to conditionally create resources based on their presence in the cluster do not behave as expected in Harness deployments. This is due to Harness rendering Helm charts client-side on the delegate, without access to the live Kubernetes cluster. As a result, lookup calls always return null, causing resources like ConfigMaps to be reapplied on every deployment—even when they already exist. Expected behavior: If the ConfigMap already exists in the namespace, Helm should skip creating it again. Actual behavior: Harness re-renders the chart locally and reapplies the ConfigMap on every deployment, overwriting any existing resource. Root Cause: All Helm rendering is performed locally by the delegate. Since lookup requires live cluster access to query existing resources, it fails to function properly in the Harness environment. Impact: Unexpected overwrites of existing Kubernetes resources Helm chart logic becomes unreliable in Harness Limits ability to use native Helm features for idempotent deployments Request: Add support for server-side Helm rendering or an alternative mechanism that enables safe resource lookup during chart rendering, allowing lookup and similar functions to behave as intended.