Feature Requests

Problem Statement: Harness has an established troubleshooting surface for inward signals (Trigger Execution Troubleshooting) where users can inspect payloads and resolution logic. However, an equivalent surface does not exist for outbound signals (Slack, Email, MS Teams, Datadog, and Git PR Status updates). Because these are currently handled as asynchronous, best-effort tasks, they fail "out-of-band." This creates a scenario where a pipeline execution is marked Green in the Harness UI, but the external state is broken (e.g., a PR status check remains "Pending" indefinitely or a critical production alert is never delivered). The "False Positive" Connection Test: Connector "Test Connection" functionality typically validates network reachability or basic read access. It does not verify the specific write-level scopes or functional permissions (e.g., write:statuses for GitHub or specific channel permissions for Slack) required at runtime. A connector can return a "Success" state while being functionally incapable of completing the pipeline task. Visibility Gap & Failure Modes: Without runtime logs in the UI, users cannot self-diagnose common integration failures: Expired/Rotated Tokens: Credentials that have become invalid since the last connection test. Provider Rate Limiting: Throttling from external APIs (e.g., GitHub's 5000/hr limit) that causes updates to be dropped. Missing Scopes: Tokens that lack the specific permission to update a status or post to a sink. JEXL Resolution Errors: Payloads that become malformed during variable resolution (e.g., a null variable producing invalid JSON). Proposed Solution: Implement an "Outbound Delivery" or "External Signals" tab within the Pipeline Execution UI that provides: Request Audit: The final resolved payload sent to the external service. Provider Response: The raw HTTP status and response body (e.g., 403 Forbidden: insufficient_scope or 429 Too Many Requests). Traceability: Direct correlation between the planExecutionId and the specific delivery task. Value: MTTR Reduction: Enables customers to diagnose integration issues without requiring Harness Support intervening, being bottleneck Feedback Reliability: Ensures the Harness execution status accurately reflects the state of the broader CI/CD ecosystem.

We operate an internal developer platform that manages Harness Vault Secrets Manager connectors on behalf of customers. We own the connector lifecycle; customers own the credentials. On provisioning we can preflight credential validity before creating the connector. Our issue is the update path — credentials can expire between onboarding and a later reprovisioning event. The only signal we currently receive is a failed terraform apply. We investigated test-connection as a pre-flight check, but it returns success even after credentials are invalidated. This was confirmed through both the Harness UI and REST API (POST /ng/api/connectors/testConnection/{identifier}). To reproduce: provision a Vault connector with valid credentials, invalidate them, run test-connection (observe success), then run terraform apply (observe failure). We expect test-connection to exercise the same validation path the Terraform provider uses during create/update, so a successful test reliably indicates a reprovision will succeed.

When testing a policy against a pipeline execution, there is no filter for the name of the pipeline. The filters are "Entity Type", "Organization", "Project" and "Action". Can you add an input box to filter the pages of pipelines that come back in the existing results? This would make it much easier to find the correct pipeline rather than scrolling through pages of pipeline executions, especially if the pipeline was not recently executed.

Secrets referenced through JEXL expressions, for example <+secrets.getValue(" account.my _secret")> inside step settings, plugin configs, or shell scripts, are resolved at runtime but are not recorded as references. As a result, the Referenced By tab and the Secrets API show zero usage even when the secret is actively used by live pipelines. Request: detect and track expression-based secret usage, surface it in the Referenced By tab, and expose it via the Secrets API so admins can perform reliable impact analysis before rotation, restriction, or decommissioning. Example: account-level secret harness_svc_account_token is used via secrets.getValue() in plugin step settings across two active pipelines on the default branch (main), yet shows no references in the UI or API.

When a delegate is pinned to a specific version with an image override, the delegates list page gives no visual indication that the override is in effect. The upgrader keeps running, so the page still shows AUTO UPGRADE: ON. That is accurate, but it reads as though the delegate will move to the latest version, when it is actually held on the pinned tag. There is no way to tell from the UI that a pin is active, or which version it is pinned to. What we would like: - A visible indicator on the delegates list (and delegate detail) when an image override is active, for example a "Version pinned" or "Override active" badge. - The pinned tag value shown alongside it (for example 26.06.89405). - Ideally the override scope (account / org / project) and expiry, so the pin's lifetime is visible. - Clear disambiguation from AUTO UPGRADE: ON, since both states coexist today and can look contradictory. Why it matters: Teams that pin a delegate version (often as a stopgap while holding a fix) cannot confirm from the UI that the pin applied, or see which version it is on, without making an API call. A visible indicator lets admins self-serve that check.

The Run Pipeline form shows "No manifest chart versions found" when the chart version picker cannot populate. This message is ambiguous -- it covers at least three distinct states: The manifest's chart version field is hardcoded (not set to Runtime Input), so there is nothing to fetch. The Helm repo is transiently unreachable. The chart genuinely has no published versions. A customer in case (1) sees the same message as cases (2) and (3) and has no way to know the root cause is their own service config. They spent an entire day hardcoding the chart version as a workaround before discovering the fix was to set the field to Runtime Input ( <+input> ). What we need When the chart version field is not set to Runtime Input, the Run Pipeline form should display a distinct, actionable message. For example: "Chart version is fixed in the service config. Set it to Runtime Input to enable version selection here." When the field is Runtime Input but the fetch fails (repo unreachable, no versions), the current error path is appropriate, but it should include a retry affordance or at least a timestamp so the user knows whether the empty state is fresh or stale. Why it matters The current generic empty state silently conflates a user-fixable config issue with a transient platform or registry failure. Customers cannot distinguish between the two without reading the service YAML or opening a support case. A targeted message would let users self-serve the fix in seconds. Use case A user adds a second Helm manifest to a service and leaves chart version hardcoded. On the Run Pipeline form the version picker is empty with no explanation. The user assumes a platform or registry problem and spends significant time debugging before discovering the field needs to be set to Runtime Input in the service config.

Our account is currently utilizing an active usage-based licensing model where we have a target of 500 active licenses . Under this agreement, active users are dynamically determined by activity (e.g., triggering a pipeline or making a commit) within the last 30 days. Inactive users are automatically excluded from the billable seat count after 30 days of inactivity. The Issue: The Harness Account Subscription panel / dashboard (at https://app.harness.io/ng/account/.../settings/subscriptions ) displays prominent "License Limit Exceeded" or "Overuse" warning banners. These warnings appear to be triggered simply by the total number of registered users in our account, rather than the actual active monthly usage that determines our billing. This discrepancy creates significant confusion, generates false alarms for our engineering leadership, and results in wasted administrative cycles trying to determine if we are out of compliance. Requested Enhancements: Update the Account Subscription dashboard to display metrics and warnings based on the actual billing model of the account (i.e., the active user cohort over the trailing 30 days), rather than the absolute count of registered users. Ensure that "License Exceeded" banners and alerts are only displayed if the actual active usage cohort exceeds the agreed limit. Provide in-dashboard tooltips explaining the licensing model terms (e.g., "Your account is on active monthly usage licensing. Registered users who have been inactive for 30 days are automatically excluded from billing." ).

On many screens, such as org lists, project lists, etc, the platform doesn't allow the ability to right click and open in a new tab. This make updates, cross referencing, and support across multiple orgs, projects, and pipelines a more difficult and lengthy process.

I would like the ability to ctrl/cmd + click on an entry in the project/organization browser screen and have that project open in a new tab, retaining the current screen. Behavior today is it will open that new project in the same tab, or it will open it in a new tab but also open the project in the current tab

a Way to configure Profile Pictures as a User inside Harness. Optional: OIDC User Profile Endpoint Integration so that the SSO Profile Picture is used / auto configured for more consistency.