Feature Requests

I created a custom notification template and tried to get the start and end times for pipeline events using JSON format, but Harness only supports the epoch format for these expressions. I need the times to be shown in UTC format instead. Could you help us by supporting to generate UTC format values for the pipeline events.

Description: Customers are unable to import Harness API Docs into Postman: Downloading openapi-merged.json fails. Importing openapi-merged.yaml causes Postman to hang. Expected Behavior: openapi-merged.json should download successfully. openapi-merged.yaml should import into Postman without issues. Impact: Prevents effective API testing and slows developer workflows.

Customers need the ability to use expressions to dynamically configure the Build Intelligence Connector at the Account, Org, Project, or Pipeline level. Today, connector selection is statically set, which forces duplication across pipelines and makes it difficult to standardize Build Intelligence behavior in large enterprise environments. Requested Behavior: Support Harness expressions in the Build Intelligence Connector field Allow a centrally defined default (Account or Org level), overridable downstream if necessary

Enable Harness CCM Autostopping Rules to include an additional condition based on tag key-value pairs, not just the target resource. Summary: Enhance Harness CCM Autostopping Rules to support conditional execution based on tag key-value pairs, allowing rules to apply to multiple resources but only execute when specific tag conditions are met. Current Behavior: Autostopping Rules can be assigned to individual resources (e.g., EC2, RDS) but cannot include logic to evaluate tags before taking action. As a result, rules cannot dynamically adapt to deployment or environment state changes controlled by external systems. Requested Enhancement: Allow Autostopping Rules to include an additional condition that checks for one or more tag key-value pairs before executing an action.

Many pipelines generate a run-specific JSON report (e.g., deployment summary, compliance results). Today, Harness email notifications can include text and variables, but they cannot attach the JSON file that was just produced by the pipeline. Teams resort to workarounds (upload to S3/GCS and share a link), which is clunky and risky. Currently, when a pipeline generates a file (e.g., a deployment report or status JSON), the only way to share it with recipients is by either embedding the content into the email body or hosting it externally (e.g., S3) and sharing a link. It would be very useful if Harness provided the ability to attach a file (e.g., JSON) generated during pipeline execution directly to the email notification. This will help teams share pipeline artifacts more effectively with stakeholders without relying on external storage or manual steps. ✅ Impact: Improves notification efficiency, enables better auditability, and reduces dependency on external storage systems. 🚀 Target Users: DevOps engineers, release managers, SREs, QA teams, and stakeholders receiving deployment updates.

Currently the TAS services can be deployed using CF CLI 7.0. This feature request is to enable the support for TAS deployments using CF cli 8.0

We have a security requirement that needs us to utilize Bearer tokens instead of other authentication. Harness JFrog Connectors do not seem to support bearer authentication.

The new GCE Instance Flexibility feature will greatly help with Waze's reliability, especially for important services that are currently under capacity constraints (e.g. services requiring C2/C4 cores). From reading the documentation ( https://cloud.google.com/compute/docs/instance-groups/configure-instance-flexibility#terraform_1 ), a new instance_flexibility_policy field is introduced to the instance template, which Spinnaker doesn't know how to parse and configure. We will like to have Spinnaker supporting this feature.

Right now the rollback steps can only run on certain types of non-successes (namely Failures and I believe Expiries), which leaves some potential issues unkept/unattended when pipelines are aborted or otherwise. Ideally, we want to be able to optionally perform some kinds of rollback steps on any type of status of the pipeline other than success.

In IDP as of now we can only update integration and cannot delete them, we should have an option to delete integrations too