Web/App End User Monitoring: Custom Metrics: Enable Alerts Based on Actual Metric Values, Instead of Only Count of Custom Metrics

In our Website Monitoring using the INEUM SDK, custom metrics are recorded and correctly displayed on default dashboards. However, when configuring smart alerts, we are restricted to using only the count of custom metric events. We cannot create alerts based on the actual metric values (such as duration or other numeric values), which limits our ability to monitor performance effectively.

Problem Statement:
While the default dashboards display the full set of custom metric fields, the alerting functionality is limited to event counts. This restriction means that:

Actual custom metric values (e.g., duration, custom numeric values) are not available for defining alert thresholds.

Alerts cannot be triggered based on the actual performance data, impacting timely detection and response to issues.

IMPORTANT: We specifically mean CUSTOM METRICS, not the default metrics.

Proposed Enhancement:

Alert Configuration Improvement:
Enhance the EUM smart alert interface to enable selection of provided actual custom metric fields (e.g., duration, custom numeric values) as the basis for alert triggers rather than being limited to event count.

Threshold-Based Alerts:
Allow users to define alerts that trigger when a custom metric exceeds or falls below a specified threshold, providing a more precise monitoring mechanism.

Business Impact:

Proactive Monitoring:
Alerts based on actual metric values will facilitate earlier detection of performance issues and allow for more targeted responses.

Improved Incident Management:
By triggering alerts on actual metric thresholds, teams can quickly address performance degradations, improving overall service reliability.

Operational Efficiency:
Enhanced alerting capabilities ensure that critical performance issues are not overlooked, thereby minimizing downtime and improving user experience.

Use Case Example:
A web application reports a custom metric measuring the latency of a specific user action. Although this metric is visible on the default dashboard, the alerting system only permits alerts based on the number of events. This limitation prevents setting an alert for when the action latency exceeds a critical threshold, delaying the detection of performance issues. Enabling alerts based on the actual latency metric would allow teams to react promptly to performance degradations.

Code Sample:
Below is an example of how a custom metric with latency might be reported in the web application using the INEUM SDK:

javascript:

// Report a custom metric for user action latency
 ineum('reportEvent', 'userActionLatency', {
  timestamp: Date.now(),
  duration: 350, // latency in milliseconds
  
  backendTraceId: '31ab91fc109223fe',
  error: null,
  componentStack: 'ExampleComponent > SubComponent',
  
  meta: {
    userStatus: 'active'
  },
  
  customMetric: 350 // numeric value representing latency
  
});

Expected Alert Configuration:
With the enhanced functionality, when creating a smart alert in the Website Monitoring interface, the alert configuration screen would allow selection of the actual metric field (for example, "duration" or "customMetric") rather than defaulting to "Occurrences." / count of metrics in time bucket.

For instance, the user should be able to:

Select Field: Choose "duration" from a drop-down list of custom metric fields.

Define Condition: Set a threshold such as "duration > 300 ms."

Trigger Alert: Have the alert trigger when the reported latency exceeds the defined threshold.

This capability would enable more granular and meaningful alerts based on real performance data.

Conclusion:
We request that Instana implement an enhancement to the EUM smart alerting functionality, allowing alerts to be created based on actual custom metric values (such as latency/duration) instead of only on the count of events. This change is critical for achieving more accurate and proactive website monitoring and will significantly improve operational responsiveness.

Thank you for considering this feature request.

We look forward to your feedback.