Written by: Nimesh Chakravarthi, Co-founder & CTO, Struct
Key Takeaways for Faster RCA with New Relic and Struct
-
New Relic surfaces strong APM signals, deployment markers, traces, logs, and Errors Inbox, yet engineers still spend 30+ minutes manually correlating data across views during incidents.
-
Each of the five recommended New Relic workflow steps leaves manual effort: mapping blast radius, confirming commits, interpreting trace waterfalls, checking error history, and authoring runbooks.
-
Real-world incidents involving multiple services, non-deployment triggers, or junior engineers without tribal knowledge routinely stretch investigation time to 45–60 minutes.
-
Struct automates the full RCA workflow by ingesting metrics, logs, traces, and code the moment an alert fires, then delivers a correlated root cause and impact summary directly in Slack.
-
Teams that automate their on-call runbook with Struct cut triage time by about 80% and protect SLAs without waking senior engineers at 3 a.m.
The 3 a.m. Alert Fatigue Scenario for On‑Call Engineers
An alert fires at 3:07 a.m. The on-call engineer acknowledges it via PagerDuty, opens New Relic, and starts a familiar sequence: APM summary, recent deployments, trace waterfall, logs, Errors Inbox. Each tool surfaces a fragment of the picture. Manual root-cause identification can take hours or days when engineers sift through millions of log messages, scanning backward to identify known error indicators and unusual behavior. As systems grow larger with cloud-native architectures, manual investigation slows down significantly, and the cognitive cost of context-switching between tools while half-asleep compounds every minute of delay.
For teams bound by strict SLAs, where every minute of investigation directly erodes the resolution window, this manual stitching is not a minor inconvenience. It is a structural risk.
See how Struct eliminates manual correlation
To understand exactly where those minutes disappear, walk through the recommended New Relic workflow step by step and track both time and manual effort.
New Relic Root Cause Analysis Workflow in Five Steps
The following five-step workflow represents the recommended sequence for using New Relic to investigate a production incident. Each step includes a realistic time estimate, the required inputs, and the manual effort that remains after New Relic surfaces the data.
Step 1: APM Signals and Anomaly Detection (≈2 minutes)
Open the affected service in New Relic APM. Review throughput, error rate, and response time charts to establish when degradation began. New Relic anomaly detection baselines normal behavior and flags deviations, which narrows the time window of interest. Engineers still spend considerable time manually searching through metrics, logs, and traces to connect the dots, which significantly delays resolution and keeps MTTR unnecessarily high.
Still manual? Yes. Identifying which downstream services are affected requires navigation to each dependency’s APM view individually. New Relic surfaces the signal, and the engineer maps the blast radius.
Step 2: Deployment Markers for Fast Causal Clues (≈1 minute)
Check the APM timeline for deployment markers overlaid on the error rate chart. A spike that aligns with a recent deploy provides a strong causal signal. New Relic deployment marker integration with CI/CD pipelines makes this correlation visual and fast.
Still manual? Yes. Confirming which commit or feature flag introduced the regression requires cross-referencing the deployment marker with the GitHub diff. That step forces a context switch outside New Relic.
Step 3: Distributed Tracing and Logs-in-Context (≈3 minutes)
Navigate to Distributed Tracing, filter by the affected service and time window, and identify slow or erroring trace spans. Logs-in-context links log lines directly to the trace, which removes the need to manually correlate trace IDs across separate log queries. The classic RCA workflow uses traces to narrow where a problem occurred and log messages to determine why it happened by revealing spikes in errors and warnings.
Still manual? Yes. Interpreting the trace waterfall and deciding which span introduced latency and why still requires engineering judgment. New Relic presents the data, and the engineer draws the conclusion.
Step 4: Errors Inbox and Custom Fingerprinting (≈2 minutes)
Open Errors Inbox to review grouped error occurrences, stack traces, and affected user counts. Custom fingerprinting rules allow teams to group related errors that New Relic default grouping separates, which reduces noise. Assign the error group to the relevant owner directly from the inbox.
Still manual? Yes. Determining whether an error group is new, regressed, or a known flap requires institutional knowledge or a manual search through prior incidents. Investigating individual alerts rather than unified incident views increases the time required for root cause identification.
Step 5: Notebooks for Reproducible Runbooks (≈2 minutes)
Document findings in a New Relic Notebook and embed the relevant charts, NRQL queries, and narrative context. This creates a reproducible artifact for post-incident review and future on-call reference.
Still manual? Yes. Writing the narrative, selecting which charts to embed, and structuring the runbook for future engineers remains entirely human-authored. The Notebook functions as a documentation tool, not an investigation accelerator.
Why New Relic RCA Still Takes 30+ Minutes in Real Incidents
The five steps above assume ideal conditions: clean logs, a single affected service, a recent deployment as the obvious cause, and an engineer with deep system context. Real incidents rarely cooperate. Traditional monitoring tools that analyze signals independently fail to preserve context across infrastructure, network, cloud, and application domains, making it harder to understand how failures propagate.
When the root cause spans multiple services, involves a non-deployment trigger such as a third-party API, a database query plan change, or a traffic spike, or lands on a junior engineer without tribal knowledge, the ten-minute ideal stretches to 30, 45, or 60 minutes. Each additional tool consulted, including AWS CloudWatch, Sentry, or GitHub, adds a context switch and a fresh authentication step at 3 a.m.
New Relic Intelligent Root Cause Analysis (iRCA), announced in February 2026, uses a real-time topology graph, advanced causal models, and a path-based ranking algorithm to identify probable root causes in seconds. iRCA meaningfully compresses Step 1 and Step 3. It does not remove the need for a human to validate findings, cross-reference code changes, write the incident summary, or execute a fix.
Automated RCA with Struct Inside Slack
Struct integrates directly into Slack and PagerDuty alerting channels and begins investigation the moment an alert fires, before the engineer opens their laptop. Struct automatically root-causes engineering alerts by pulling and analyzing metrics, logs, traces, monitors, and code, performing regression analysis, correlating anomalies, and generating impact summaries.
The table below maps each manual New Relic step to the Struct automated equivalent.
|
New Relic Step |
Manual Effort Required |
Struct Automation |
Engineer Action |
|---|---|---|---|
|
APM signals and anomaly detection |
Per-service navigation, manual blast radius mapping |
Auto-queries all affected services and generates a blast radius summary in Slack within minutes |
Review summary, no navigation required |
|
Deployment markers RCA |
Cross-reference marker with GitHub diff in a separate tab |
Correlates deployment events with error spikes and links to the relevant commit automatically |
Confirm or dismiss the suggested cause |
|
Distributed tracing and logs-in-context |
Filter traces, read waterfall, correlate log lines |
Ingests traces and logs across the stack and surfaces the offending span with correlated log evidence in a unified timeline |
Read the pre-assembled timeline |
|
Errors Inbox and fingerprinting |
Group errors, check recurrence history, assign owner |
Deduplicates error groups, flags regressions versus known flaps, and posts impact count to the Slack thread |
Assign fix, no manual grouping needed |
|
Notebooks for runbooks |
Author narrative, embed charts, structure for future reference |
Generates a dynamically built dashboard with supporting charts, queries, and a structured incident report |
Export or share the auto-generated report |
This automation translates to measurable time savings for large-scale customers, who report the 80% reduction mentioned earlier holds true across diverse incident types. Setup takes under 10 minutes through OAuth connections to Slack, GitHub, and observability platforms. Struct is SOC 2 and HIPAA compliant, which makes it suitable for fintech, healthtech, and other regulated U.S. engineering teams operating under strict SLA windows.
How to Improve RCA Quality with Better Telemetry and Runbooks
RCA quality degrades when the investigation relies on incomplete telemetry, skips the deployment correlation step, or produces findings that the next on-call engineer cannot reproduce. Three practices consistently improve output quality.
First, maintain structured trace IDs across all services so logs can be correlated without manual effort. This practice removes the most time-consuming step in cross-service investigations.
Second, encode runbooks in a machine-readable format so automated tools can follow the same diagnostic path a senior engineer would. This approach keeps investigations consistent across shifts.
Finally, treat every incident report as a living document that feeds back into alert tuning. This habit allows each investigation to reduce noise for the next one. Automated RCA solutions continuously learn from historical incidents to reduce MTTR over time, which means the quality of automated investigations improves as incident history accumulates.
What Are Common RCA Mistakes in Production Teams?
The most frequent RCA mistakes in production engineering environments share a common thread: they sacrifice thoroughness for speed. Engineers stop at the first plausible cause rather than confirming it against all available evidence and treat correlated events as causal without checking the deployment timeline.
Even when the root cause is correct, failing to document findings in a format that a junior engineer can act on independently means the next incident requires the same manual investigation from scratch. In environments generating large amounts of data, human analysts may overlook patterns when manually scanning log files and analyzing event correlations. A second common failure involves siloing the investigation inside a single tool. APM data without log context, or log data without trace correlation, produces an incomplete picture that leads to misattributed root causes and recurring incidents.
Frequently Asked Questions
Is AI-assisted RCA mature enough to trust in 2026 for production incidents?
Yes, with appropriate validation. Automated RCA tools in 2026 operate on the same telemetry signals, including metrics, traces, logs, and deployment events, that experienced engineers use manually. The difference lies in speed and consistency, because automated systems do not skip steps under pressure or lose context when switching tools.
Struct investigations carry an 85–90%+ helpful rate, which means the automated output provides the correct root cause and actionable next steps in the large majority of cases. Engineers retain full control to validate, override, or extend any finding before acting on it. The practical model uses automated first-pass investigation reviewed by a human, not autonomous remediation without oversight.
How much engineering effort does rollout require, and what if our telemetry is incomplete?
Struct connects through OAuth to Slack, GitHub, and observability platforms in under 10 minutes, with no dedicated engineering sprint required. The quality of automated investigations scales with the quality of existing telemetry.
Teams already using structured logging, trace IDs, and a tool like Datadog, Sentry, or AWS CloudWatch see high-quality outputs immediately. Teams with sparse or unstructured logs receive partial investigations. Struct surfaces what the data supports and flags where evidence is missing rather than fabricating conclusions. The recommended starting point is to ensure basic trace ID propagation and error alerting are in place before enabling auto-investigations.
Does Struct meet U.S. compliance requirements for teams under strict SLAs?
Struct is SOC 2 and HIPAA compliant. Log data is accessed and processed ephemerally, and it is not stored beyond the investigation window. For the majority of Seed-to-Series-C U.S. companies in fintech, healthtech, and SaaS, this compliance posture covers standard contractual and regulatory requirements.
Teams with enterprise mandates that require full on-premise deployment or zero-egress log policies should evaluate Struct Enterprise tier, which includes sidecar and on-prem support options, before committing to a rollout.
Conclusion: Replace Manual Triage with Automated RCA
New Relic is a capable observability platform. Its APM views, deployment markers, distributed tracing, Errors Inbox, and iRCA features each reduce the time required to investigate a specific signal. The remaining gap is synthesis. An engineer must still navigate between views, correlate findings across tools, and produce a structured incident report under time pressure at any hour of the day. That gap is where 30-plus minutes disappear.
Struct closes that gap by running the full investigation automatically the moment an alert fires and delivering a correlated root cause, blast radius summary, and dynamically generated dashboard to the Slack thread before the engineer is fully awake. The investigation that previously consumed a senior engineer’s most cognitively demanding minutes becomes a five-minute review.
For on-call teams at U.S. companies operating under SLA pressure, the arithmetic stays straightforward. An 80% reduction in triage time means more SLAs protected, more engineers sleeping through the night, and more product velocity returned to the roadmap.
