Most performance investigations feel the same: You know something is worth examining, your dashboards confirm it, and then you spend hours clicking through data trying to find the thread that ties it all together. I’ve found a faster way.
Over the past month, I’ve been using Claude Code alongside New Relic to help diagnose production issues in one of our high-throughput healthcare applications. The setup is pretty simple: Claude helps surface insights from New Relic, writes and iterates on queries, correlates application performance monitoring (APM) data with source code, and provides verification steps for engineers to run themselves. In my experience, this can all happen in a single session, often in under half an hour.
Here’s what that looks like in practice.
When we migrated between cloud storage providers, two of our highest-throughput background job workers slowed down noticeably. The dashboards showed that everything was slower, but the root cause wasn’t obvious.
I described the situation to Claude and asked it to compare transaction metrics for the periods before and after the deployment. The average transaction duration had roughly doubled, and database time was up significantly. As we continued the investigation, Claude helped identify three contributing factors: a cloud storage client being re-instantiated on every transaction instead of being reused, file downloads happening inside open database transactions, and repeated feature flag checks hitting the database in our background jobs.
Using those findings, we developed fixes for all three issues. After implementation, database duration dropped by about 50%.
Another example involved a background job that had been running for more than five hours. Claude surfaced 24 million individual database calls and helped trace them back to a CSV presenter that was loading five model associations one record at a time across nearly a million rows. This is a classic N+1 problem.
Based on the investigation, Claude estimated that properly preloading those associations could drop the worst-case runtime from 14 hours to around 15 minutes. We used that analysis to develop the change, and two engineers on the team reviewed the PR within 30 minutes of posting it. We merged it that day.
The third example started with a service that stopped accepting connections. Claude used pattern matching across a large volume of log lines to identify a client sending hourly file bursts. When members of the team pushed back that this alone shouldn’t explain the issue, we kept looking.
The deeper investigation uncovered a separate pattern of failed connections accumulating over time. That gave us a much clearer picture of the underlying problem — and the fix we actually needed.
What makes this workflow valuable isn’t that Claude replaces engineering judgment. Every fix still gets human review. Every PR still goes through the normal process. What changes is the speed at which you can move from “something is worth investigating” to “here’s why, and here’s how we might fix it.”
Having a tool that can hold the full context of a problem, help iterate on queries, and correlate APM data with source code in a single session changes what’s possible on a code red call. It gives engineers a faster path through the investigative work while keeping validation, review, and implementation where they belong: with the engineering team.
One practical note from what we’ve learned: Be specific about what you observed and when, but resist the urge to tell Claude what you think the cause is. Give it the context, then let the evidence lead the investigation.
