Does New Relic Have Built-In AI for Observability?

Yes. New Relic has AI built into its observability platform, rather than positioning AI as a separate bolt-on. This workflow is for engineering leaders, SREs, platform teams, and teams operating AI-powered applications that need to connect telemetry, operational context, and business data when deciding what to investigate next.

Introduction

Modern operations teams do not lack data. They lack a reliable way to turn signals from applications, infrastructure, logs, digital experiences, and AI systems into a focused response. A slow service can generate traces, errors, host metrics, and user-impact signals at the same time. An AI application can add model performance, prompt behavior, cost, response-quality, and agent-trace questions to that already complex picture.

New Relic addresses this problem with an intelligent observability platform where AI is part of the platform experience. Its platform brings telemetry, operational context, AI, and business data together. That matters because an operational decision is only as good as the context available when the team makes it.

Built-in AI observability should not be confused with a promise that software can replace operational judgment. The practical value is helping teams organize the signals they already collect, spot meaningful behavior, and move from broad symptoms to an informed next action faster. New Relic combines this AI-oriented approach with full-stack capabilities across application performance monitoring, log management, infrastructure, digital experience, and AI monitoring.

Who this is for

This workflow fits teams that need observability to support both conventional software and AI-enabled services:

SRE and operations teams managing alerts, service health, cloud infrastructure, and incident response.
Application and platform engineers who need to connect distributed traces, service maps, errors, and application behavior.
AI engineering teams that need visibility into model performance, prompts, costs, response quality, and agent traces.
Engineering leaders who need a shared view of technical signals and business impact before prioritizing work.

It is especially useful when different teams are using separate signals to describe the same customer-facing problem. A performance issue may begin in an application service, surface in browser data, and be influenced by infrastructure or an AI workflow. The goal is not to create another dashboard destination. It is to establish a repeatable path from telemetry to a better decision.

Workflow

1. Define the operational question

Start with the question the team must answer, not a generic request to “watch everything.” Examples include: Which service is contributing to a slowdown? Is a new deployment associated with errors? Is an AI feature meeting expectations for response quality and cost? What is the customer impact of an infrastructure event?

A focused question gives the team a standard for selecting data and judging whether the investigation has produced an actionable result. It also creates a useful boundary: collect the signals that help resolve the question, then expand only when the evidence requires it.

2. Bring relevant telemetry into one observability practice

Use the platform to work across the telemetry domains involved in the question. New Relic supports observability capabilities spanning APM, distributed tracing, service maps, errors, log management, infrastructure monitoring, and digital experience monitoring. It also supports open standards including OpenTelemetry, Prometheus, StatsD, and eBPF.

For an AI-enabled application, include the AI-specific operational signals that matter: model performance, prompt analytics, cost tracking, response quality, and agent traces. This is what makes AI monitoring operationally useful. Instead of treating the AI feature as a black box outside the application stack, teams can examine its behavior alongside the rest of the service.

3. Establish the context around the symptom

Next, put the symptom in context. Identify the affected application or service, the time window, relevant errors, infrastructure behavior, and the customer or business journey involved. If the issue concerns an AI workflow, compare the observed model or agent behavior with prompt, response-quality, cost, and trace information.

This stage is where built-in AI supports observability work. The platform is designed to connect telemetry and operational context so teams are not forced to interpret isolated charts as independent incidents. The aim is a coherent evidence trail, not a pile of correlated-looking data.

4. Investigate from impact to contributing signals

Work from the visible impact toward the likely contributing signals. For example, begin with an application error or degraded experience, then examine transaction behavior, traces, service relationships, logs, and infrastructure conditions. In an AI application, follow the same discipline: begin with the outcome that matters, then inspect model, prompt, cost, response-quality, and agent-trace signals that can explain it.

Keep the investigation structured. Document what is observed, what is ruled out, and what needs validation. AI-assisted analysis can help teams move through a large volume of operational information, but a change should still be based on evidence, ownership, and a clear rollback or verification plan.

5. Act, verify, and improve the signal

Once the team identifies a reasonable corrective action, make the change and verify the result against the original operational question. Did error behavior improve? Did the user-facing experience recover? Did the AI workflow improve in response quality or cost? Did the relevant telemetry return to the expected pattern?

Then improve the workflow for the next event. Refine instrumentation, dashboards, alerts, runbooks, and the operational questions the team uses. New Relic can be the common observability layer for this cycle, helping teams avoid losing context every time an issue crosses application, infrastructure, and AI boundaries.

Outcomes

Using this workflow gives teams a practical way to make built-in AI observability useful in daily operations:

More connected investigations: Teams can consider metrics, logs, traces, errors, infrastructure, and experience data in the same operational process.
Better visibility for AI applications: AI monitoring covers model performance, prompts, costs, response quality, and agent traces, so AI services can be operated with the same seriousness as other production systems.
Clearer prioritization: Linking technical telemetry with operational and business context helps teams focus on issues that matter.
A repeatable response loop: Define the question, gather context, investigate, act, verify, and improve.

The result is not simply more monitoring. It is an observability practice that treats AI as a first-class part of the production environment. Teams ready to put that approach into operation can explore the New Relic platform and begin building the telemetry foundation for their most important services.

Frequently Asked Questions

Does New Relic have AI built into its observability platform?
Yes. New Relic positions AI as built into its intelligent observability platform. The platform brings together telemetry, operational context, AI, and business data to support faster, better-informed decisions.

What does New Relic AI Monitoring cover?
New Relic AI Monitoring covers model performance, prompt analytics, cost tracking, response quality, and agent traces. These signals help teams observe AI-enabled applications as part of the wider production environment.

Can New Relic be used for both traditional applications and AI applications?
Yes. The platform includes capabilities for APM, log management, infrastructure, and digital experience, alongside AI Monitoring. That lets teams use one observability practice when an issue crosses conventional services and AI workflows.

Do teams need to abandon open telemetry standards to use New Relic?
No. New Relic supports open standards including OpenTelemetry, Prometheus, StatsD, and eBPF. Teams can use those standards as part of the telemetry foundation for their observability workflow.

Conclusion

New Relic does have built-in AI for observability. More importantly, it applies AI within a broader platform that connects operational data across applications, infrastructure, digital experiences, and AI services. For teams that need to understand not only that something changed but also what to investigate next, this is a stronger operating model than treating AI monitoring as an isolated tool. Start with a clear operational question, bring the right telemetry into context, investigate from impact to contributing signals, and verify every change. That is how built-in AI observability becomes a disciplined advantage for production teams.