AI SRE for New Relic
The agent layer on top of your APM.
Your team runs New Relic. Alerts fire. Dashboards are already built. Traces are there when you go looking. But every incident still needs an engineer to piece the signals together, open five tabs, read the deploy history, and work out what actually broke.
Sherlocks AI is the agent that does that work. On top of New Relic. In minutes. Before the on-call opens their laptop.
sre@prod-bastion ~ $ sherlocks investigate --source newrelicAGENT FINDINGtrace agent slow span: query on orders tabledeploy agent PR #1842 merged 23 min agoinfra agent RDS CPU 40% -> 94% after deploywatson root cause posted to #incident sre@prod-bastion ~ $ sherlocks connect newrelic --read-only
Who this is for
Platform, SRE and DevOps teams running production on New Relic who are tired of:
- Alerts that tell you something broke but not what, or why
- 2 AM pages where the first 20 minutes is just gathering context
- New Relic AI answering questions, but no one answering “what do I do now”
- Every incident costing a senior engineer’s evening
If any of those sound familiar, keep reading.
What Sherlocks AI adds to New Relic
(05 Things)- 01
Alert to root cause in minutes, not hours.
When New Relic fires an alert, Sherlocks AI is already investigating. By the time the on-call engineer sees the page, it has pulled the APM data, correlated with the recent deploy, checked the infra side, and posted the likely root cause with evidence in Slack.
- 02
Investigation across the full stack, not just the APM.
New Relic sees your application. Sherlocks AI sees your application plus your Kubernetes cluster, your AWS or GCP control plane, your GitHub deploy history and your Slack incident channel. Every investigation stitches those sources together, not just the ones inside New Relic.
- 03
Agent-first, read-only by default.
Sherlocks AI does not change anything in New Relic. It reads your APM data, your logs, your infrastructure metrics and your alert configuration with scoped, read-only keys. Nothing is written back.
- 04
Watson plus 16+ specialized agents, orchestrated.
Watson is the lead investigator. Behind it, specialized agents handle trace analysis, log correlation, deploy diffing, dependency mapping and more. Each agent is good at one thing. Watson decides which ones to run.
- 05
VPC-deployable. SOC 2 Type 2.
Your New Relic data never leaves your network. Sherlocks AI runs inside your VPC, connects to your New Relic account over scoped credentials, and keeps the investigation context in your boundary. For security and compliance teams, this is the question that usually kills AI SRE evaluations.
New Relic AI vs Sherlocks AI
They do different things. Both can be on at the same time.
| New Relic AI | Sherlocks AI | |
|---|---|---|
| Primary job | Answer questions about your New Relic data | Investigate incidents end to end |
| Trigger | Someone types a question in the UI | A New Relic alert fires, or a page is received |
| Scope | Inside New Relic | New Relic + Kubernetes + cloud + deploys + Slack |
| Output | Conversational response | Root cause + evidence + suggested next step |
| Action | Read-only | Read-only |
| Where it lives | New Relic UI | Slack, your incident channel |
If New Relic AI is a librarian, Sherlocks AI is a detective. Teams running both use New Relic AI for ad-hoc exploration and Sherlocks AI for the actual incident response loop.
How it works
(04 Steps)- 1Step 1: Sherlocks AI reads from your New Relic.
Connect over scoped API keys. New Relic exposes its data through NerdGraph, its GraphQL API, and NRQL queries run through the same endpoint, so there is no agent to install and no extra pipeline to build. Watson and the specialized agents work with APM traces, logs, infrastructure metrics and alert context.
- 2Step 2: An alert fires.
New Relic sends the alert through the channel your team already uses, Slack or PagerDuty. Sherlocks AI catches it at the same time. New Relic workflows can send one alert to several destinations at once, so teams that page through Opsgenie, incident.io or a webhook keep that path and add the Slack channel Sherlocks AI watches.
- 3Step 3: Investigation starts.
Watson routes the alert to the right agents based on the signal. Each agent runs its specific checks: trace analysis, recent deploys, infra health, dependency mapping, log patterns. Everything in parallel.
- 4Step 4: Root cause lands in Slack.
A single post in your incident channel: the likely root cause, the evidence that supports it, and a suggested next step. Linked back to the exact New Relic trace, log line and deploy that got Sherlocks AI there.
Example investigation
The alert
New Relic APM fires on p95 latency for checkout-service. Threshold is 800 ms. Current is 2.4 s.
Alert
The alert hits PagerDuty.
Sherlocks AI catches it.
Fan-out
Watson pulls the trace data from New Relic APM. Three agents start in parallel:
- Trace agent: identifies the slow span (DB query to the orders table)
- Deploy agent: pulls GitHub deploys for checkout-service in the last 2 hours
- Infra agent: checks RDS metrics for the orders DB
Findings
The findings come back.
Trace agent flags the slow query as a new query pattern not seen before today. Deploy agent finds PR #1842 merged 23 minutes ago by a teammate. Infra agent flags RDS CPU at 94%.
Synthesis
Watson stitches it together.
Post
The root cause lands in #incident-checkout-latency.
The card below.
Handoff
The on-call engineer opens Slack.
Investigation is done. They make the call on revert versus forward-fix.
Likely root cause
PR #1842, merged 23 minutes ago, introduced a new query pattern against the orders table. The query is missing an index on user_id + status. RDS CPU climbed from 40% to 94% after the deploy. Rolling back or adding the index should resolve it.
Evidence
- New Relic trace: the slow span on the orders query
- Deploy: PR #1842 in checkout-service
- RDS CPU graph: New Relic infrastructure metric, last 2 hours
Suggested next step
Revert PR #1842, then add the index in a follow-up.
Data and permissions
- APM traces and transaction data
- Infrastructure metrics
- Log data (if enabled)
- Alert configuration and alert history
- Entity map and dependencies
- Nothing. Sherlocks AI reads from New Relic and never writes to it.
- No alert conditions changed, no data pushed, no configuration touched.
- Scoped, read-only API keys (one per environment)
- Rotatable keys: revoke one in New Relic and that environment is disconnected
- Reads only, through NerdGraph, the same path as any dashboard
- SOC 2 Type 2
- VPC deployment option: Sherlocks AI runs inside your network, and your data never leaves
- Air-gapped deployment for regulated environments
- Metadata and metrics only, never raw application data, PII or secrets
Read-only. Watson reads from New Relic and never writes to it. It does not push data, change alert conditions or modify your New Relic configuration.
Running Datadog or Prometheus next to New Relic? The Datadog page and the Prometheus and Grafana page cover those sides, and the Kubernetes page covers what Watson reads from inside the cluster.
Setup
(05 Steps)- 1
Create a New Relic user API key with read-only scope. A user key carries the permissions of the user who created it, so create it from a read-only user and the key cannot do more than that user can.
- 2
Add the key to your Sherlocks AI workspace under Integrations, then New Relic.
- 3
Pick the accounts and environments Sherlocks AI should see.
- 4
Connect your alert source: the Slack channel your New Relic alerts post to, or PagerDuty.
- 5
Test with a canary alert.
The docs cover deployment, integrations and routing alerts.
Frequently asked questions
(09 Questions)Does Sherlocks AI replace New Relic?
No. New Relic stays as your observability platform. Sherlocks AI runs on top of it as the agent layer.
Does it work with New Relic's native alerts, or do I need a paging tool?
Either path works. Sherlocks AI picks up the New Relic alerts your team routes to Slack, and it integrates with PagerDuty for teams that page from there. New Relic workflows can send one alert to several destinations at once, so teams on Opsgenie, incident.io or a webhook keep that path and add the Slack channel Sherlocks AI watches.
What's the latency added to my New Relic usage?
None. Sherlocks AI reads through the New Relic API, which is the same read path as any dashboard. Nothing is ingested into New Relic, so your data usage does not change.
Does it work with New Relic infrastructure monitoring, not just APM?
Yes. Sherlocks AI reads infrastructure metrics, logs and APM data from the same New Relic account.
Can it run on-prem or air-gapped?
Yes. VPC deployment is supported, and air-gapped deployment is available for regulated environments. Contact sales for a fully air-gapped setup.
How does it handle noisy alerts?
Sherlocks AI runs the investigation whether the alert is real or noisy. If the investigation returns no root cause, no recent deploys and healthy infrastructure, that itself is a useful signal that the alert may be a threshold issue, not a real incident. Over time, teams use the output to tune their New Relic alerts.
What about New Relic AI?
Both can run at the same time. New Relic AI answers questions about your New Relic data inside the New Relic UI. Sherlocks AI investigates incidents end to end, across New Relic and the rest of your stack, and posts the root cause in Slack.
Does it need write access to New Relic?
No. All permissions are read-only. Sherlocks AI cannot change alert conditions, push data or alter your New Relic configuration.
How much does it cost?
The free plan includes 30 investigations per month, with no card required. Paid plans scale with volume. See the pricing page for details.
Ready to try it
Start free with 30 investigations per month, no card. Or book a 30-minute demo and see Sherlocks AI run an investigation against a live New Relic account.
Questions? Get in touch.