New Relic Reliability Engineer common mistakes
New Relic Reliability Engineer · Understand the traps and how to avoid them.
Reading a service's Apdex score as a percentage of successful requests and reporting it as the error rate during an incident, then chasing the wrong service.
Apdex is a satisfaction ratio built from a threshold T (satisfied, tolerating, frustrated) and looks like a percentage, so candidates treat it as an error or success metric. On the exam, scenarios that give a low Apdex alongside healthy error rates are testing whether you separate latency-driven dissatisfaction from actual failures.
What to do instead
Before answering, restate what each metric measures: Apdex = (satisfied + tolerating/2) / total, driven by the T threshold and response time distribution, not by HTTP status. When a question shows low Apdex with low errors, look at slow transactions, external service latency, or a poorly chosen T. Reserve error rate and throughput for failure analysis.
Diagnosing a slow request by inspecting only the top-level web transaction, missing that most of the time is spent in a downstream service or datastore call that appears as a single segment.
Candidates memorize the APM UI hierarchy but do not practice reading distributed traces or transaction breakdowns. They answer with the entry-point service because that is where the alert fired, ignoring where the time actually accrued.
What to do instead
Practice walking a trace end to end: identify the span with the largest exclusive duration, then check whether it is an external call, a database query, or queue wait. In answers, always name the segment or downstream entity responsible and how you confirmed it (span duration, database call counts, external service metrics).
Treating browser (Browser monitoring) and mobile (Mobile monitoring) data as interchangeable, or attributing slow page loads to backend APM when the delay is client-side rendering or third-party scripts.
The Digital Experience domain overlaps with APM, and candidates default to server metrics. They forget that Browser and Mobile agents capture Core Web Vitals, JavaScript errors, AJAX timing, and device or network context that APM cannot see.
What to do instead
Map the symptom to the data source: page load and Core Web Vitals, JS errors, and AJAX calls point to Browser; crashes, network errors, and device/OS breakdowns point to Mobile; server response time points to APM. For third-party script or CDN delays, cite Browser session traces or AJAX timing rather than server-side transaction time.
Assuming an AI-assisted feature (applied intelligence, anomaly detection, or an alert correlation feature) will automatically resolve or suppress an incident, and answering that no human action is needed once it is enabled.
Marketing framing around AIOps leads candidates to overstate automation. Exam scenarios reward knowing the boundary: these features surface anomalies, correlations, and candidate root causes, but configuration, thresholds, and remediation decisions remain with the engineer.
What to do instead
In answers, describe the AI feature as producing a signal (anomaly, correlation, suggested cause) and then state the human or automated workflow that consumes it: alert policy routing, runbook, or incident response. Never claim the feature replaces alert policy design or on-call judgment.
Sizing or interpreting host and container metrics without accounting for the difference between infrastructure agents and integrations, or ignoring that containerized workloads report at pod, node, and cluster levels.
Candidates study metric names but not the collection topology. They answer with a host CPU number when the bottleneck is a container CPU throttle, or they miss that a Kubernetes integration supplies cluster-level data separate from the host agent.
What to do instead
For each infrastructure question, state the entity (host, container, pod, cluster), the collector (infrastructure agent versus an integration such as the Kubernetes or cloud provider integration), and the metric that answers the question (CPU throttling, memory working set, node pressure). Cross-check with the entity's own dashboard before concluding.
Dropping or over-filtering logs during ingestion to cut cost, then discovering the fields needed for an investigation were never stored, or writing queries that scan far more data than necessary.
Cost pressure pushes candidates toward aggressive sampling or exclusion rules without planning retention and query needs. They also underestimate how partition, attribute, and time-range choices affect query performance and billing.
What to do instead
Design log pipelines around investigative questions: keep high-value attributes, use parsing and enrichment at ingest, and set retention per data type. When writing queries, constrain by time range, partition or attribute filters, and specific fields; verify with a small range before running broad searches. In exam answers, justify sampling only for high-volume, low-value logs.
Designing alert policies that fire on raw static thresholds for every entity, producing alert storms, then answering that the fix is to raise thresholds rather than restructure the policy.
Candidates learn the alert condition syntax but not the operational design: baseline and anomaly conditions, gap filling, evaluation windows, and incident correlation. They default to static thresholds because those are easiest to describe.
What to do instead
For alerting scenarios, choose the condition type that matches the signal (static for known limits, baseline or anomaly for variable workloads), set evaluation windows that avoid flapping, group related signals into one incident, and route by severity. If a question describes alert fatigue, propose policy consolidation and correlation before touching thresholds.
Treating OpenTelemetry as a drop-in replacement that requires no mapping work, and answering that OTLP data automatically matches New Relic semantic conventions, entity relationships, and dashboards.
Candidates know OTel is a standard but not the translation layer: resource and span attributes must map to entity identification and metric conventions for data to appear correctly and correlate with existing entities.
What to do instead
Describe the pipeline explicitly: collector receivers, processors (including resource and attribute mapping), exporters to OTLP endpoints, and how service.name and related resource attributes determine entity identity. Note that without correct mapping, data arrives but entities, dashboards, and alerts may not line up.
Answering security and risk questions by listing every vulnerability finding as equally urgent, instead of prioritizing by exploitability, exposure, and business context.
Candidates conflate detection with prioritization. They report raw scanner output or CVSS scores without considering whether the asset is internet-facing, whether the vulnerable path is reachable, and whether the library is actually loaded at runtime.
What to do instead
Rank findings using reachability and runtime evidence, exposure of the asset, severity, and blast radius. State the decision rule you applied: fix internet-facing, reachable, high-severity issues first; deprioritize unreachable or non-runtime dependencies with a documented rationale and monitoring.
Describing dashboards and fleet or configuration management as a manual, per-entity activity, missing that dashboards should be driven by variables and that agent and configuration changes should be rolled out and verified centrally.
Hands-on habits from small environments carry over: editing one dashboard per team or SSHing to update one agent. Candidates then answer scalability questions with manual steps that would not survive a large fleet.
What to do instead
For dashboard questions, use template variables, linked entities, and shared building blocks so one dashboard serves many services. For fleet questions, describe central configuration, staged rollout, health verification, and rollback. Name the mechanism and the verification step, not just the intent.