Automating Anti-Pattern Detection

Site Reliability Engineers and platform developers understand performance anti-patterns. The concept of an N+1 database query or a bloated frontend payload is standard textbook material. Yet, when we look at real-world telemetry across enterprise environments, a startling reality emerges: while engineers know these issues exist, an estimated 95% do not realize these anti-patterns are actively executing in their own production systems. Paradoxically, it is because modern applications are so resilient that these inefficiencies often fail silently, below the radar. The page still loads, the transaction still completes, and the infrastructure automatically scales to handle the load. To the naked eye, performance looks “acceptable.”

However, this acceptable performance carries a massive, hidden cost. In today’s cloud-native architecture, performance issues are no longer just about user wait times; they are directly tied to your infrastructure bill. Consider a recent post by a former New Relic PM: if you don’t know how to optimize the specific queries feeding your infrastructure, you could easily be wasting $70,000 a year over- provisioning GPUs or cloud compute just to keep poorly written application logic afloat. You are paying a premium to subsidize bad code.

To bridge this gap between theoretical knowledge and production reality, we have introduced Performance Risks Inbox. This new product is designed to automatically detect these latent, silent anti-patterns across your stack. More importantly, it shifts the narrative from abstract engineering chores to concrete business outcomes, explicitly showing you the “carrot”: the exact dollar amount you will save, or the specific user experience metric you will improve, by resolving the risk.

Categorizing the Chaos: Cost Analyzers vs. Speed Analyzers

To make sense of the massive volume of telemetry generated by modern applications, Performance Risks Inbox doesn't just passively collect data; it actively interrogates it. It relies on specialized detection engines known as analyzers. These analyzers continuously evaluate your incoming data streams against a strict set of known architectural anti-patterns, surfacing only the actionable signals.

To help SREs and engineering leaders prioritize their triage efforts, we have broadly split these analyzers into two distinct, outcome-driven buckets:

• Cost-Themed Analyzers: Inefficient database calls are one of the fastest ways to silently inflate your infrastructure bill. Every redundant query or massive data pull requires compute power, memory, and bandwidth. To combat this, the initial release of Performance Risks Inbox includes four primary database analyzers squarely focused on cost reduction. These engines automatically hunt down notoriously expensive anti-patterns, such as N+1 Queries, Sequential Queries, Excessive Queries and the like, giving you the precise data needed to optimize your code and immediately lower your monthly spend.
• Speed-Themed Analyzers: While the database dictates your cost, the frontend dictates your user experience. Even if your backend is highly optimized, rendering bottlenecks and payload bloat can create severe latency for the end user. To tackle this, we are launching Performance Risks Inbox with two initial frontend analyzers designed to detect the specific friction points that degrade load times and disrupt the customer journey.

Learn more about our analyzers and the way they work in the documentation.

Looking Ahead to Future Analyzers

This initial set of six analyzers is just the foundation. As application architectures evolve, so does Performance Risks Inbox. Looking ahead, we are expanding our footprint to include four additional speed-themed analyzers to help you further eliminate frontend bottlenecks.

More importantly, as generative AI becomes standard in the enterprise tech stack, we are actively developing a new class of AI-specific analyzers. Designed for teams integrating with models like OpenAI and Claude or testing autonomous agents, these upcoming analyzers will detect complex LLM anti-patterns, ensuring your platform is future-proofed against the next generation of performance risks.

Getting Started: Zero Configuration, Immediate Value

One of the biggest hurdles to adopting new observability tools is the dreaded “configuration fatigue.” SREs and engineers simply do not have the time to manually instrument new code, write custom regex, or guess at what baseline thresholds should be set to get a feature working. With Performance Risks Inbox, we have entirely eliminated that friction. For New Relic APM & Browser users, the capability is already fully integrated into the platform. There are no feature gates to unlock or complex installations to manage, so you can simply navigate to Performance Risks and start triaging.

The Power of Defaults

The reason you can get immediate, workable results on day one is due to our default configuration. Instead of asking you to define what a “performance risk” looks like in a vacuum, New Relic sets the baseline thresholds using the P75 metrics of our entire aggregated global dataset. Because the platform has analyzed how optimal systems behave at a massive scale, Performance Risks Inbox already knows what a dangerous N+1 query or a latent frontend payload looks like out-of-the-box. These defaults are adjusted periodically to enhance the quality of issues that get detected.

Effortless Fine-Tuning

While these defaults cover the vast majority of use cases, we know that every environment is unique. If you have a specific microservice where the default doesn't quite align with your internal service level objectives (SLOs), fine-tuning the system is entirely code-free. Performance Risks Inbox allows you to set up custom thresholds at both the Account and Entity level, giving you the ability to fine-tune precisely. Moreover, you don't need to open your IDE or deploy configuration changes. Adjusting your risk sensitivity is as simple as editing a text, directly within the New Relic UI.

Pro Tip: If you want to visualize how your specific telemetry compares to these thresholds before making adjustments, we provide a downloadable dashboard template. You can instantly import this dashboard into your environment to view your numbers, giving you the confidence to fine-tune your settings with precision.

Workflow Walkthrough: From Detection to Remediation

Preset defaults and outcome-driven analyzers are only useful if they translate into a clear path to action. To see how the pieces fit together, let's follow a single risk from the moment it surfaces to the moment your telemetry confirms it is gone.

The Scenario

Imagine you run the platform team for an e-commerce company, and you are a week out from a seasonal sale. Nothing is on fire. Every dashboard is green, checkout completes, and orders are flowing. Underneath that calm, your checkout-service is quietly loading each item in a shopping cart with its own database call, so a five-item cart fires five separate lookups against the product catalog instead of one. This is a textbook N+1 query. It never trips a health check, because each individual query is fast and the page always renders. What it does do is multiply your database load, hold connections open longer, and add cost and latency that scale directly with cart size, exactly when you least want them to.

Step 0: The Overview

Before you triage anything, you need to know where to look. You start at the Performance Risks overview, an account-level page that answers a single question: which entities in your estate carry performance risk right now, and how much does each one matter? Rather than making you open every service by hand, the overview lists each monitored entity that has at least one active risk, alongside the signals you need to rank them: the count of open risks, their trend, and an aggregate impact rollup attributable to that entity. 

This gives you the account-wide picture, the total number of at-risk entities, and the way they are trending, so an engineering leader can size the opportunity at a glance. In our example, checkout-service surfaces near the top and that is your cue: this is the service to open first.

Step 1: The Performance Risks View

Clicking into checkout-service opens its Performance Risks Inbox, which provides a prioritized feed of risk cards rather than a wall of raw alerts. Each card represents a specific anti-pattern that comes from a trace or transaction that an analyzer has confirmed for this entity. Your N+1 Query risk sits at the top of the list, tagged by the analyzer that caught it. You can filter the feed based on multiple required attributes and sort by Last Seen, Newest, or Occurrences. If you prefer a different layout, you can bypass the default grouping and instead group based on custom attributes by switching to 'Group performance risks'. More filters and saved views are coming soon, ensuring that a platform engineer chasing infrastructure spend and a frontend engineer chasing load times will each see their relevant work first. The ultimate goal is to triage by business impact, not by volume.

Each card also carries a familiar triage experience similar to that of the Errors Inbox, allowing you to seamlessly create a Jira ticket, assign it to a team member, and track the status changes of a detected performance risk.

Step 2: Understanding the Details

Selecting an individual performance risk opens its details view, which instantly grounds the abstract problem in concrete data. Right away, the interface surfaces the exact database query causing the bottleneck, along with performance risk group metrics that paint a stark picture of the inefficiency. You can clearly see the average N Value and duration for that specific group.

As you scroll through the pane, visual evidence solidifies the diagnosis. The Occurrences and Query duration charts confirm this is a consistent architectural flaw rather than an isolated latency spike. The view also provides immediate access to the full list of attributes, including the exact span and trace IDs. This gives you everything you need to either pivot straight into a distributed trace or leverage New Relic’s AI tooling to help formulate a fix.

We are also working on a deeper integration with Intelligent Workloads that dynamically draws the blast radius. Instead of showing the checkout service in isolation, the dependency map places it as the source and traces the ripple outward to the services that sit downstream of it. This clearly answers the question, “Why did the problem stay invisible?” Because no single service breached its own service level objective, nothing paged anyone. Yet, the repeated catalog lookups saturate connections and push queue depth up, compounding that delay across every service in the workload. This domino effect is exactly what turns a "fast enough" individual query into a measurable drag on the entire customer journey.

Step 3: Drilling Down

From the details view, you can drill into the evidence. One click takes you from the high-level risk into a representative distributed trace, where the waterfall makes the pattern impossible to miss: dozens of near-identical spans stacked inside a single transaction. Expanding a span exposes the specifics an engineer needs to know in order to act, including the db.statement, the datastore, the per-call duration, and the code-level stack trace that points at the class and method issuing the calls.

If you would rather interrogate the data yourself, the card links straight to the underlying query so you can confirm the scope across live traffic. You can corroborate the same story at the transaction level using the databaseCallCount and databaseDuration attributes on the Transaction event, which confirm that the checkout path is firing one query per cart item rather than a single batched read. At this point, there is no guesswork left: you have the exact service, transaction, query, and line of code.

Step 4: The Fix

The remediation itself is an ordinary refactor. You replace the per-item lookups with a single batched query or an eager load that pulls the whole cart's products in one round trip, and then you ship it through your normal deployment pipeline. Nothing needs to change inside New Relic because the Performance Risks Inbox is continuously evaluating live telemetry against the same baselines that raised the risk. If it sees the anti-pattern reappear, a regression is automatically raised.

To help you act on these insights, the Performance Risks Inbox allows you to move seamlessly from detection to resolution in three ways:

1. AI Summary: Generate an instant, actionable summary based on the exact data we have collected.
2. MCP Tooling: Leverage New Relic MCP to bridge the gap between telemetry and your codebase, helping you debug the issue directly within your IDE.
3. Automated Remediation (limited preview): We are currently working on an integration with the New Relic SRE Agent with a limited set of customers, allowing the agent to automatically deploy a fix for detected risks.

Takeaways and Resources

Optimizing code shouldn't be an abstract academic exercise, nor should it be a task reserved only for the aftermath of a major outage. With Performance Risks Inbox, we have transformed performance optimization from a guessing game into a repeatable, data-driven workflow. By explicitly connecting engineering metrics to business outcomes, SREs and platform developers can confidently prioritize the fixes that will actively lower their cloud bills and accelerate their user experiences. Stop paying to subsidize bad code, and start letting your telemetry point you directly to the solution.

Prerequisites and Requirements

Before you get started, ensure your environment meets the following requirements:

• Distributed Tracing: This must be enabled for your services. The Performance Risks Inbox relies heavily on trace data to detect performance risks.
• AI Summary: This feature requires active access to NRAI.
• Performance Risks MCP: This feature requires active access to New Relic MCP.

Questions? Reach out in the New Relic Community Forum