Feature Requests

Need Teams using Harness and Datadog need access to native deployment metrics (not just events) to reliably measure release outcomes and define SLIs/SLOs around deployment reliability. Current Limitation Harness primarily sends deployment information to Datadog as events. While useful for visibility, events are not suitable for long-term trend analysis or SLI/SLO definitions, and require teams to derive metrics indirectly. Requested Capability Support emitting Datadog metrics for key deployment signals, such as deployment success, failure, rollbacks, and duration, with standard tagging (service, environment, pipeline).

It would be great if Monitored Service Health Source supports elastic APM. The logs from elastic are supported currently

I'm proposing an enhancement to integrate Dynatrace Grail metrics within our Continuous Verification (CV) framework. By leveraging the Dynatrace Calculated Metrics API—specifically, the "Get Metrics on Grail" endpoint (documentation: https://docs.dynatrace.com/docs/discover-dynatrace/references/dynatrace-api/configuration-api/calculated-metrics/service-metrics/get-metrics-on-grail)—we can capture critical support metrics that are currently unavailable. Key Benefits: Enhanced Visibility: Integrating Grail metrics will provide deeper insights into service performance and support trends, greatly improving our monitoring capabilities. Unblock Migration Efforts: We have transitioned our Dynatrace tenants from GCP to AWS to leverage Grail. This move highlights the necessity for our integration to support these metrics, ensuring a seamless CV experience. Improved Continuous Verification: With more comprehensive metrics available, CV can deliver proactive incident detection and resolution, leading to more robust performance management.

Following the release of the feature enabling automatic CD rollback triggered by SLI/SLO breaches (Long CV), we're suggesting a refinement to the rollback trigger logic. Currently, rollback is triggered when the SLO budget remaining is exhausted over the evaluation window. The customer recommends enhancing this behavior to react immediately to an SLI breach, rather than waiting for the budget to deplete. Proposed Enhancement: Update the SRM module to support rollback triggers based on direct SLI threshold violations, in addition to or instead of relying on SLO budget calculations. This would allow faster response to critical regressions and better alignment with customer expectations around real-time SLI monitoring. Benefits: Faster rollback in response to critical anomalies More accurate alignment with customer-defined SLIs Greater flexibility in rollback strategy

Hi Harness Team, I'm reaching out to request an update to our Harness Dynatrace integration. Currently, our setup requires marking requests as key to collect metrics. However, due to our limitations, we can't mark any key requests, which is blocking us from fully utilizing Continuous Verification (CV). Switching to the new Dynatrace API would remove this dependency and also allow us to capture infrastructure metrics from the pods we deploy—something the current integration doesn't support. Metrics should not be limited solely to services in Dynatrace; infrastructure metrics need to be included as well. Key Benefits: Eliminate Current Limitations: By removing the need to mark key requests, we can collect comprehensive metrics without relying on a workaround. Enhanced Monitoring: The new API will provide full visibility, including infrastructure metrics from our deployment pods. Currently, custom metrics are tied only to key requests, which restricts our ability to monitor metrics beyond that scope.

Currently, the Elastic search connector uses the https://elastic.co endpoint by default for the connection tests. Due to this, in private networks where we do not allow traffic to https://elastic.co , it is hard to use this connector. Please provide support for passing the custom healthcheck endpoint in the Elasticsearch connector, this can be a internal private Elasticsearch instance.

For Pipeline and SLO Breach Failure Notifaction, we need OpsGenie OOB Connector

Harness uses standard PromQL for a prometheus data source? or does Harness parse and translate before querying? for example, i started out using the query builder to generate a base query: sum(My_Success_Metric{service="my-service"}) which returns a data set. But when I update it to this: sum(My_Success_Metric{service="my-service"}) + sum(My_Failure_Metric{service="my-service"}) Harness throws an error about not being able to parse it - it looks like the + causes the error: {"status":"error","errorType":"bad_data","error":"1:83: parse error: unexpected \u003caggr:sum\u003e"} If we URL encode the value using '%2b' it seems to work. Is it possible to use vanilla pomql without URL escaping? From Harness which url encodes those special characters on harness end, in the middle-ware, before passing the data along to prometheus. The query user paste into harness should work in prometheus, or grafana, or anywhere else where pomql is used?

We are trying integrate elasticsearch instance from 3rd party service. It only supports header based authentication, but on the UI is not available, please advice. Thanks

I would like the ability to configure a Client Credentials OAuth2.0 authentication flow for the SRM custom health connector.