New Relic Smart Alerts uses historical telemetry to recommend alert coverage

The problem with manually maintained alerts

In a blog post by Douglas Braun, a Product Marketing Manager at New Relic, the company argues that the traditional alerting model has become costly to sustain. Engineers decide what to monitor, create alert conditions, configure them and maintain them as systems change. That worked well, New Relic says, when environments were relatively stable and the number of systems was manageable.

Modern applications now span services, containers, Kubernetes clusters, cloud infrastructure, databases and third-party dependencies, and they keep changing after monitoring is set up. According to the post, teams are therefore not simply creating alerts but continually trying to keep coverage aligned with an environment that "refuses to stand still." Across thousands or tens of thousands of entities, New Relic says, this becomes an operational problem of its own.

What Smart Alerts does

Smart Alerts analyzes historical telemetry to recommend alert conditions, coverage and monitoring best practices based on how an organization's systems have actually behaved. New Relic positions these recommendations as an informed starting point, so engineers do not have to begin every monitoring decision from scratch.

The company is explicit about the limits of the approach:

• Smart Alerts is not based on the idea that thresholds should move automatically as application behavior changes.
• It does not eliminate thresholds, which New Relic says remain useful for many monitoring scenarios.
• Engineers still make the decisions that reflect their organization's operational priorities.

New Relic also says the feature helps spread good practice. Experienced engineers often know which conditions matter for a type of service, but applying that knowledge consistently takes time, and different teams may configure similar systems differently. Using telemetry-based recommendations, the company says, can help establish monitoring across large numbers of entities without repeating the same configuration process.

On alert noise, the post says the aim is better coverage quality rather than more alerts. In its words, "The goal is not more notifications." It is greater confidence that important systems are monitored appropriately without unnecessary operational burden.

Where it fits in an AI-driven strategy

New Relic links the feature to the growing use of AI in operations. Engineering teams are beginning to rely on AI to investigate incidents and navigate complex operational data, but the post argues that better models alone will not guarantee better outcomes. Context matters, and teams still need to separate conditions that warrant attention from the large volume of normal activity.

Smart Alerts is part of New Relic's broader Autonomous Operations strategy, according to the company. Its role is not to investigate incidents, orchestrate agents or remediate problems autonomously. It sits earlier in the operational lifecycle, helping establish scalable alert coverage so meaningful signals can be identified more consistently. Other capabilities can then combine telemetry with operational context and AI-assisted reasoning.

What it means for engineering teams

For engineering teams, New Relic says the benefit is practical: less time repeatedly configuring monitoring and more time improving the applications and experiences customers depend on. Teams can spend their effort evaluating whether the recommended coverage reflects what matters to their applications and customers, rather than building it by hand.

The post also frames a wider shift for observability, from collecting operational data to learning from it. New Relic says the value of telemetry can compound over time as it feeds better recommendations and richer context. The post does not give pricing, availability details or performance figures for Smart Alerts.