New Relic is a full-stack observability platform that ingests metrics, events, logs, and traces (MELT) from across your entire stack into a single unified database (NRDB), queryable with its SQL-like NRQL language. It matters because engineering teams need a single pane of glass to correlate APM data, infrastructure health, browser/mobile performance, and log streams without context-switching between tools. The key mental model: everything in New Relic is an entity — an application, host, service, or synthetic monitor — and entities can be grouped, mapped, and alerted on through a consistent interface regardless of how the data arrives (agent, OTel, or API).
What This Cheat Sheet Covers
This topic spans 18 focused tables and 161 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Platform Structure — Organizations, Accounts, and Users
New Relic's account model determines how data is isolated, who can see it, and how billing is calculated. Getting the hierarchy right before onboarding prevents painful data-access problems later.
| Concept | Example | Description |
|---|---|---|
A company signs up → one organization is created | • Top-level container • holds all accounts, users, and billing for a New Relic customer | |
Invoice processing prod vs. Invoice processing dev | • A data silo within an organization; all telemetry requires an account ID to be stored. • Free/Standard editions: single account only • Pro/Enterprise: can add multiple accounts | |
1234567 used in API calls and agent config | • Unique numeric identifier • required for every API call and agent configuration | |
SRE/developer who builds dashboards and responds to alerts | • Has access to all New Relic capabilities • primary billing dimension alongside data ingest |