Is New Relic Down? How to Check New Relic Status Right Now

There's a particular kind of dread reserved for the moment you realize your monitoring platform is down. Dashboards are empty. APM traces stopped flowing. Alert policies that should have fired — didn't. You're not sure if production is on fire or if you've just gone blind, and the tool you'd normally use to answer that question is the thing that's broken. It's the "who monitors the monitor?" problem, and every team that runs New Relic long enough will eventually hit it.

Here's how to confirm New Relic is down right now, understand exactly which components are affected, and make sure your on-call rotation isn't the last to know next time.

Is New Relic Down Right Now?

Check these three sources in order — they give you progressively broader signal:

1. Statusfield — New Relic status — continuous external monitoring updated in real time, independent of New Relic's own infrastructure.
2. Twitter/X — search New Relic down sorted by Latest. Developers and SREs across thousands of orgs are quick to surface agent reporting gaps, UI errors, and alert silences publicly. If it's affecting multiple accounts, the feed will show it within minutes.
3. Downdetector — aggregates user-reported outages. Less granular than component-level detail but useful to confirm widespread impact.

What Actually Breaks During a New Relic Outage

New Relic is a multi-component observability platform. An outage rarely means everything stops at once — it typically means one or more pipelines (ingest, query, alerting, UI) degrade independently. Knowing which components are affected tells you how bad the situation actually is.

Component	What it does	Impact when down
APM agents	Language agents (Java, Node, Python, Ruby, Go, .NET, PHP) instrument your application and stream telemetry to New Relic ingest	Agent data stops flowing; APM dashboards go stale or show "No data"; error rates and throughput become invisible
Dashboards / UI	NRDB-backed browser interface for querying, charting, and alerting	Engineers can't view metrics even if ingest is healthy; queries time out or return errors
Alert policies	NRQL- and metric-based conditions that trigger incidents and notify on-call	Alert silence — conditions that should fire don't; on-call is never paged; incidents go undetected
Distributed tracing	Trace context propagation and visualization across services	Trace waterfall views disappear; cross-service latency attribution is lost; root cause analysis is manual
Log management	Log forwarding and querying via the Logs UI and NRQL	Application logs stop appearing; WHERE ... AND log.message queries return nothing; log-based alerts fall silent
Synthetic monitors	Scheduled HTTP checks and scripted browser tests	Synthetic checks stop executing; uptime SLAs can't be measured; external availability alerts don't fire
Browser monitoring	JavaScript agent tracking real-user metrics (Core Web Vitals, JS errors, AJAX)	Frontend performance visibility drops; JS error alerts silenced; page load data stops
Infrastructure agents	Host-level metrics (CPU, memory, disk, network) from newrelic-infra	Infrastructure dashboards go blank; host-based alerts (disk full, CPU spike) don't fire
NerdGraph API	GraphQL API for programmatic access to metrics, configurations, and entity data	Automation, CI/CD integrations, and custom dashboards that query NerdGraph break; API returns 5xx

New Relic Error Symptoms and What They Mean

What you see	What it usually means
"Agent is not reporting" banner in APM	The language agent has lost connectivity to New Relic's ingest endpoint — or the ingest endpoint itself is degraded; check Statusfield to rule out a platform-wide event
Alert policies silent during a known incident	Alert evaluation pipeline is degraded; conditions are not being evaluated against incoming data even if ingest is partially working
Dashboard shows "An error occurred" or endless spinner	NRDB query infrastructure is degraded; the data may exist but can't be queried
502 / 503 errors on one.newrelic.com	New Relic's frontend CDN or application layer is down; affects only UI access, not data ingest
Logs UI shows "No logs found" for time ranges with active traffic	Log ingest pipeline is down or severely delayed; data may backfill once recovered
Distributed trace "No traces found" despite active requests	Trace ingest or sampling service is degraded; parent/child span correlation is broken
Synthetic check "Job not completed" or results missing	Synthetic runner fleet is degraded; scheduled checks are queued but not executing
newrelic-infra shows healthy but host metrics missing	Infrastructure ingest endpoint is degraded; the agent is running and collecting but can't forward data
NerdGraph returns {"errors":[{"message":"Internal server error"}]}	NerdGraph API layer is degraded; retry with backoff before assuming a query bug

How New Relic's Architecture Affects Outage Scope

New Relic runs a large-scale distributed ingest and query platform. Understanding how it's structured helps you predict blast radius during an incident:

US vs EU data centers are separate. New Relic operates distinct data residency regions — US (metric-api.newrelic.com) and EU (metric-api.eu.newrelic.com). An outage affecting US data centers may leave EU-region accounts completely healthy, and vice versa. If your account is on EU data, check Twitter for European-timezone engineers reporting issues before concluding the platform is globally down.

Ingest and UI are separate systems. Data ingestion (agents pushing telemetry to New Relic's collectors) and the query/UI layer (NRDB queries powering dashboards) are architecturally independent. It's common to see a UI outage where dashboards fail to load but agents are still successfully shipping data — the data is accumulating but temporarily unqueryable. Conversely, an ingest failure means your dashboards appear healthy (rendering cached or last-known data) while new data silently stops flowing.

Agents buffer locally during ingest outages. New Relic language agents (APM) have a configurable in-memory queue. When the ingest endpoint is unreachable, agents continue collecting data locally for a configurable window (typically 1–5 minutes depending on the agent and configuration) before beginning to drop. Short ingest blips often result in a data gap followed by a partial backfill when connectivity recovers. Longer outages mean permanent loss of that telemetry — the buffer is finite.

Alert evaluation is downstream of ingest. Alert conditions query NRDB on a polling interval. If ingest is degraded, NRQL conditions see stale or missing data and may never evaluate to a breaching state — even if your application is actively failing. This is the most dangerous failure mode: production is on fire, but no alert fires because the monitoring pipeline is blind upstream of the alert evaluator.

NerdGraph is a separate API surface. Automation workflows that use NerdGraph (fetching entity GUIDs, modifying alert conditions, querying metrics programmatically) can fail independently of the main UI. A NerdGraph degradation doesn't mean dashboards are broken, and a UI outage doesn't necessarily mean NerdGraph is down.

Agent Reporting Gaps vs. New Relic Outages

When an APM dashboard goes dark, the instinct is to blame New Relic — but agent reporting gaps have several causes, and it's worth ruling out the local ones before escalating.

Start with the agent log on your host. Every New Relic language agent writes a local log (newrelic_agent.log for Java, /tmp/newrelic-python-agent.log for Python, etc.). Look for connection errors, authentication failures (INVALID_LICENSE_KEY), or SSL errors. A 403 Forbidden response from the collector means your license key is wrong or revoked — not a platform outage.

Check the agent's connection target. APM agents connect to collector.newrelic.com (US) or collector.eu01.nr-data.net (EU). If your production environment has egress firewall rules or a proxy, a rule change or misconfiguration on your side will produce the same "not reporting" symptom as a New Relic outage. Verify connectivity from the host itself using basic TCP reachability checks.

Look for recent deploys or config changes. A newly deployed version of your application with an agent misconfiguration (wrong license key, disabled monitoring flag, incorrect app name) will show as "not reporting" in New Relic's APM UI. If only one service stopped reporting and others are healthy, the problem is almost certainly local.

If multiple services across multiple hosts stop reporting simultaneously, the probability of a local cause drops sharply. That's the pattern that points to a New Relic ingest outage. At that point, confirm via Statusfield and Twitter before investing time in local debugging.

Compare against synthetic monitors. If your New Relic synthetic checks are also failing (or not executing), that's a strong signal the issue is platform-side — synthetics run on New Relic's own infrastructure, so a synthetic failure that correlates with agent silence points squarely at New Relic.

Hardening Your Observability Stack Against New Relic Outages

A monitoring platform is not immune to the failure modes it monitors. The teams that weather New Relic outages the best are the ones who treat it like any other critical dependency and plan for its failure.

1. Run a lightweight secondary monitor on your most critical endpoints

You don't need a full second observability platform — just enough to tell you if your top three services are up and your primary API endpoint is responding. A second tool watching your highest-value health checks means a New Relic outage doesn't also blind you to a simultaneous production incident. Statusfield covers New Relic's own status; for your application endpoints, even the free tier's 3 monitors can cover your most critical signals.

2. Configure agent-side local log retention

New Relic agents have limited buffering, but they do write detailed local logs. Increase log verbosity on staging environments so you have a debugging reference when things go wrong. In production, ensure log rotation keeps at least 24 hours of agent logs — they're your forensic record when you're trying to reconstruct what happened during a blind window.

3. Set up alert-on-alert-silence

New Relic's "lost signal" alerting feature (open violation on no data condition) can detect when an agent stops reporting — but it requires New Relic's own alert pipeline to be functional. For defense in depth, add a separate heartbeat: have your most critical service emit a metric on a fixed interval, and alert via a second channel if that metric stops. If both New Relic and your application are down simultaneously, you want at least one path to on-call that doesn't run through New Relic's alert evaluator.

4. Diversify on-call notification channels

If your entire on-call pipeline routes through New Relic alerts → PagerDuty/Opsgenie, a New Relic alert pipeline failure silences your pager. Add a direct integration from your incident management tool to at least one non-New Relic signal — synthetic uptime checks via an independent tool, a Cloudwatch alarm, or a cron-driven health ping. The goal isn't redundant tooling for its own sake; it's ensuring the pager can ring through at least two independent paths.

5. Document and test your "New Relic is down" runbook

Most teams have runbooks for application failures. Far fewer have a documented procedure for "our monitoring platform is down." Write it down: how do you confirm New Relic is down (Statusfield, Twitter, Downdetector), who decides to invoke fallback monitoring, what's the escalation path if a production incident occurs during a monitoring blackout. Test it during a scheduled maintenance window before you need it at 3 AM.

How to Stay Ahead of New Relic Outages

When New Relic degrades, your goal is to know before your users do — and ideally before your on-call rotation realizes their pager has gone silent.

Statusfield monitors New Relic continuously from external infrastructure that's entirely independent of New Relic's platform. The moment a degradation is detected, you get an alert to Slack, Discord, email, or webhook — so you know it's a known platform event, not a production incident your team needs to debug.

On the free plan you get 3 monitors — enough to cover New Relic plus two other critical dependencies — with no credit card required. The Pro plan ($29/mo) covers up to 20 services with unlimited alerts, so your entire observability toolchain is covered in one place.

→ Monitor New Relic on Statusfield — free, no credit card required

FAQ

Why are my New Relic APM agents showing "not reporting" suddenly?

"Not reporting" has several causes: (1) New Relic's ingest infrastructure is degraded — check Statusfield first; (2) a recent deploy changed your agent configuration or license key; (3) a network or firewall change on your hosts is blocking egress to collector.newrelic.com; (4) the agent process crashed or was not restarted after a host reboot. If multiple services across multiple hosts go dark simultaneously, that pattern points to a platform issue. If only one service is affected, start with the local agent log.

Is New Relic down for everyone or just my account?

Check Statusfield and search New Relic down on Twitter/X sorted by Latest. If other engineers are reporting the same symptoms at the same time, it's a platform event. If Statusfield shows operational and Twitter is quiet, the issue is likely account- or environment-specific. Also check whether your account is on the US or EU data center — incidents often affect only one region.

Will New Relic backfill missing data after an ingest outage?

Partially. New Relic language agents buffer a small amount of telemetry in memory during brief ingest outages (typically 1–5 minutes depending on the agent). When ingest recovers, that buffered data is flushed. However, data that exceeded the buffer window is lost permanently — it was never stored. For log data, a Fluent Bit or Fluentd forwarder with disk-backed queuing can preserve logs through longer outages and replay them once New Relic recovers. APM metrics have no equivalent disk-buffer option in the standard agent configuration.

Why did my New Relic alerts stop firing during a production incident?

New Relic's alert evaluation pipeline sits downstream of data ingest. If the ingest endpoint is degraded, NRQL-based alert conditions see missing or stale data and never breach their thresholds — even while your application is actively failing. This is the most dangerous failure mode of monitoring-as-a-single-point-of-failure. To protect against it: configure "lost signal" conditions that open a violation when an entity stops reporting, and add at least one alert path that runs through infrastructure independent of New Relic (a synthetic monitor via an external tool, a CloudWatch alarm on the same service, etc.).

How long do New Relic outages typically last?

Most New Relic incidents affecting a single component (UI, ingest, or alerting) resolve within 30–90 minutes. Multi-component incidents — where ingest, dashboards, and alerting are all degraded simultaneously — can extend to several hours. Alert evaluation outages tend to resolve faster than ingest gaps, since evaluation can restart immediately once the pipeline clears. Track real-time status via Statusfield rather than relying on refresh cycles.