Glossary of New Relic terms

A New Relic organization can have one or more accounts. An account can be considered a workspace: a space to monitor or analyze data relating to a specific project or a specific team. Each account has its own account ID, and that ID is used for some account-specific tasks, like making API calls. For more on why you'd create an account, see Account structure.

The word "account" is sometimes used in a more general industry sense. For example, it is sometimes used to refer to a New Relic organization, or a New Relic customer, or to a New Relic user's user record. In technical terms, though, at New Relic an account refers to an account with an account ID.

A New Relic agent is an installable piece of software that integrates with multiple types of technologies (for example, web frameworks, operating systems, and types of databases) and reports data to New Relic, usually on a specific cadence. We have agents, an infrastructure agent, a agent, and mobile monitoring agents. The various technologies that our agents integrate with are just some of our many integrations.

For more information, see:

In the context of New Relic alerts, we aggregate data into windows, and needs to determine when the current window ends and the next one begins. The aggregation_method is the logic that tells us when we have all the data for a given aggregation window. Once the window is closed, the data is aggregated into a single point and evaluated against the threshold. This field is optional. One of the following three values can be specified:

EVENT_FLOW: (Default) Each aggregation window will wait until it starts to see timestamps arrive that are past its own delay setting. Once this occurs, the data is published. Relies on the timestamps of arriving data, so wall-clock time is no longer relevant. Works best for sources that come in frequently and with low event spread (high througput metrics)
CADENCE: Classic New Relic logic where each evaluation window waits exactly as long as the aggregation_delay setting, using the wall-clock time as a timer. aggregation_delay is required when using this option. Data arriving too late will be dropped, which can cause false alerts.
EVENT_TIMER: Each aggregation window has a timer on it, set to the aggregation_timer setting. The timer starts running as soon as the first data point appears for that aggregation window (based on the data point's timestamp). The aggregation_timer is reset for each new data point that arrives for that window. Once the aggregation_timer reaches 0, the aggregation window is published. Ideal for sparse and batched data, such as cloud integrations and infrequent error logs.

In the context of alerts, streaming data is assessed on a set of aggregation windows to determine if an alert condition is breaching or recovering.

The aggregation window time is how long we'll collect data before running the NRQL query condition. The offset evaluation time is how long you want us to wait for late data before assessing it.

If a window doesn't have any data points, it's treated as a gap for loss of signal.

In the context of alerts, an alert policy is a collection of one or more alert conditions, one or more notification channels, and an Incident preference setting.

A condition contained within a policy may open an incident depending on the incident preference settings. In this case, all channels attached to the policy will generate notifications.

For an explanation of how a policy relates to other basic alerts concepts, see Concepts and workflow.

When a service or application behaves abnormally, New Relic's alerting features flag it as an anomaly. You can find anomalies in the activity feeds throughout New Relic. You can also create custom configurations to get notifications or track anomalies in other types of entities, like hosts and mobile apps.

For more information, see [anomaly detection] (/docs/alerts-applied-intelligence/applied-intelligence/proactive-detection/proactive-detection-applied-intelligence/)

The response time above which a transaction is considered tolerable. The default value is 0.5 seconds, but you can change this in your Apdex settings.

Requests that complete in less than apdex_t are rated satisfied.
Requests that take more than apdex_t, but less than apdex_f, are tolerated.
Any requests that take longer than apdex_f are rated frustrating.
For more information, see Apdex: Measure user satisfaction.

Attributes are key-value pairs attached to data objects reported to New Relic. Attributes add detail, and they're similar to tags or labels in other SaaS software. You can explore this data by querying or searching via the UI or by using the data dictionary.

Examples:

APM reports a Transaction event. This includes timing data for the transaction in a duration attribute, which might have a value of .002.
Our infrastructure monitoring reports a ProcessSample event. This includes a variety of CPU usage attributes, including a cpuSystemPercent attribute, which might have a value of .01.
Our Telemetry SDK reports a Metric data type for storing metrics, with attached attributes like metricName and newrelic.source.
Some New Relic tools allow you to report custom attributes to enhance your monitoring.
For more information about attributes in APM, see Agent attributes.

The component that collects data from New Relic agents running on an app server, mobile device, or end-user browser. While the agent is installed on a user's app server, the collectors are centrally located in our data center.

In order to contact the collector, the agent must be able to reach New Relic domains and IP addresses. (The exact domain or IP depends on the New Relic monitoring tool.) The collector receives and interprets this data, and stores it in a database. The data is then retrieved and presented in the New Relic UI and by our various REST APIs.

An event, in New Relic terms, is a data object with attached attributes. New Relic reports default event types, like Transaction and TransactionError. You can also create your own events. Events can be queried, and are used in some other features.

You can generate custom events with APM agents, the browser monitoring agent, the mobile monitoring agents, and via the Event API. Alternatively, you can add custom attributes to some existing default New Relic events.

Custom instrumentation allows you to extend New Relic monitoring to instrument code elements New Relic doesn't automatically instrument. Custom instrumentation is useful when your framework is not supported by New Relic, or when New Relic fails to pick up some element of your program. You can also use custom instrumentation to block a transaction from being reported entirely. For more information, see Custom instrumentation.

In the context of alerting, when a data source enters a breaching state, a degradation period of time begins. The degradation period is set in the condition's threshold. An incident will open if the source stays in a breaching state for the entire degradation period. In addition:

If the data source enters a non-breaching state before the entire time has elapsed, the degradation period countdown is reset, and an incident does not open.
If your alert condition threshold is configured as at least once in, the degradation period always lasts a single minute.

An external service is a service that is out-of-process relative to a service that is instrumented and reporting data to New Relic. An external service calls or is called by that instrumented service.

In most places in the New Relic UI, external services are uninstrumented services that do not report telemetry themselves to New Relic, but are observed from the outside using the data that instrumented services report about incoming or outgoing calls. For example, an external service named api.stripe.com is not instrumented and reporting data to New Relic itself, but is known to New Relic when a service instrumented with the New Relic agent makes an HTTP request to the hostname api.stripe.com.

New Relic Flex is an application-agnostic, all-in-one infrastructure integration. With it, you can build your own integration that collects metric data from a wide variety of services, and that can instrument any app that exposes metrics over a standard protocol (HTTP, file, shell) in a standard format (for example, JSON or plain text) to the terminal.

It's a recommended way to create a custom integration, because it doesn't require coding skills.

A framework is a structured collection of pre-defined functions, into which an application builder inserts their own code to build their application. A framework is not the same as a library. While a library is a collection of functions you can call as needed, a framework is a skeleton for your application. The functions in that framework then call your functions. For more about the distinction between a framework and a library, see What is the difference between a framework and a library?.

New Relic automatically instruments many common frameworks. For more about the frameworks New Relic supports, browse our solutions on Instant Observability.

Some New Relic UI pages have a health status indicator appearing next to an index of monitored entities. This is a colored bar (generally green, yellow, red, or gray) indicating the status of your app or other entity monitored by New Relic. It also indicates whether the entity has any alert policies assigned to it and whether there are any incidents.

Exceptions to the above-mentioned color palette:

Learn about service map colors
Our REST API (v2) uses orange instead of yellow for the application's health and reporting status.

At New Relic, a host means one of the following:

A physical machine is a hardware-based device with dedicated physical resources, including memory, processing, and storage. Each machine has its own OS which applications run on.
A virtual machine (VM) is the software implementation of a physical machine that executes programs like a physical machine. One or more virtual machines can run on a physical machine. Each virtual machine has its own OS and allocated virtual machine resources such as RAM and CPU.
A cloud instance is a type of virtual machine that is run in the public cloud. In this context, virtual machines and cloud instances are different from Java Virtual Machines (JVMs) and containers.

In the context of alerting, an incident is generated when the conditions defined in an alert policy is exceed. An incident record includes all of the open and close time stamps for each incident, as well as chart snapshots of the data being evaluated around the time of each incident.

You can view detailed information from the Incidents pages in the user interface. You can also select your preference for how we roll up incidents.

For an explanation of how an incident relates to other basic alerts concepts, see Concepts and workflow.

By connecting changes in host performance to changes in your configuration, infrastructure monitoring provides real-time metrics and powerful analytics that reduce your mean-time-to-resolution (MTTR).

Infrastructure is specifically designed for complex environments that need flexible, dynamic server monitoring, from a physical data center to thousands of Amazon Elastic Compute Cloud (Amazon EC2) instances and other types of integrations.

Insights was the name for the New Relic product that previously governed the reporting of custom events, and the ability to query and chart your New Relic data. These features are now a fundamental part of our platform and are no longer governed by the Insights product or name. To learn more about these features:

Event API for reporting custom events
Query and chart data
For historical reasons, the word "Insights" is still used in some places. For example:
For New Relic organizations on our original pricing model, Insights Pro is still the product name governing custom event data ingest and retention.
Some APM agents still have Insights language in their codebase. For example, the Java agent custom_insights_events configuration.
There is an API key called the Insights insert key.

At New Relic, an integration refers to a connection between a technology and New Relic that allows the reporting of data to New Relic. So, for example, our agents contain various integrations (ways to report data from various app frameworks, or operating systems, or types of databases). Other integrations take the form of a configuration or a procedure (for example, changing a setting or an API endpoint) that allows a service (for example, AWS Lambda or PagerDuty) to send data to us.

See all of our integrations.

A metric grouping issue occurs when an account sends too many differently named metric timeslice data points to New Relic, and those individual web transactions are not properly aggregated. For example, rather than a single /user/controlpanel/ metric name, you might see /user/controlpanel/alice, /user/controlpanel/bob, and /user/controlpanel/carol. For more information, see Metric grouping issues.

At New Relic, we use namespaces to help organize the data we store in the New Relic database (NRDB). From a customer perspective, the most practically relevant use of the namespace concept is how it relates to data retention. The namespace is what sets the default data retention period for various types of data. For example, in a specific account, data in the Logging namespace all share the same retention, and data in the APM namespace all share the same retention.

NerdGraph is our GraphQL API, an efficient and flexible query language that lets you request exactly the data you need, without over-fetching or under-fetching. NerdGraph calls get all the data you need in a single request. NerdGraph also makes it easier to evolve APIs over time and enables powerful developer tools.

You can use our NerdGraph API explorer to view the schema and find definitions. Take a look at our tutorial, or go right to the NerdGraph API explorer.

In the context of our logging management feature, this is a security protocol that hides sensitive data in your logs through hashing or masking. After you've identified sensitive data you want to hide, you define it in the form of an expression. With that expression, you create an obfuscation rule that identifies instances of sensitive data in your logs, then automates masking or hashing, depending on the rule.

At New Relic, "organization" can refer to one or more concepts:

For New Relic account management purposes, a "New Relic organization" refers to all the assets and data belonging to a New Relic customer (for example, their accounts, their users, and their data). For more about this concept, see Organization and account structure.
We sometimes use "organization" in a general way to refer to a business or non-profit entity.

With page load timing, New Relic monitors the full load time for end-user browsers. New Relic application agents dynamically inject JavaScript into the page, then capture the following key load points:

Navigation start: The user initiates the transaction.
First byte: The browser receives the requested page.
DOM ready: The browser has finished parsing DOM.
Page ready: Page loading is complete.
Page load timing is sometimes referred to as RUM, or real user monitoring. Unlike standard RUM, page load timing also captures JavaScript errors and AJAX requests. For more information, see Page load timing process.

New Relic organizations can have a parent/child account structure. This structure was much more important for organizations with users on our original user model, but is still relevant for some features for organizations with users on our newer user model. The first account created in a New Relic organization is essentially the parent account: one impact of this is that that account is where the usage and billing data is reported to.

Learn more about account structure.

Parent accounts were previously referred to as master accounts, and child accounts were previously referred to as sub-accounts.

A unique URL that links to a view of New Relic at a specific point in time. Permalinks are useful for troubleshooting and for sharing interesting time windows with colleagues. On many New Relic UI pages, you can find the permalink icon at the top right of the UI. For more on this, see Platform basics.

As of May 2023, these links expire if they haven't been used in the past six months. Note the following about the six-month pruning routine:

Since permalinks are not user specific, an older link you haven't used in six months may still be active if another user happens to make the same query.
Links using the old long-form URL with Base64 never expire.

The component of New Relic that connects to your website to verify your website is accessible. New Relic has pingers in Europe, Asia, and the United States. Each pinger attempts to contact your website at least once every two minutes. If enough pingers are unable to reach your website, your application will be considered down.

For in-depth scriptable testing, including real browser tests and tests of API endpoints, see synthetic monitoring. Synthetic monitoring includes free ping monitoring, which allows you to monitor your website from locations around the world. For more information, see Types of synthetic monitors.

Our Amazon integrations query your AWS services according to a polling interval, which varies depending on the integration. Each polling interval occurs for every AWS entity. For example, if you have thirteen Amazon elastic load balancers (ELB), each one will be polled every five minutes.

Depending on the AWS integration, there may be delays in the timing between the API request and the metric data returned. If you notice unusual delays, follow the integration troubleshooting procedures.

At New Relic, quickstart refers to all methods of installation needed to get you one or both of the following:

Additional (in addition to our curated dashboards) accessible from the Dashboards UI
Pre-built alerts
Quickstarts are featured on our Instant Observability pages: for example, this page includes a quickstart for .NET that gets you an extra dashboard and pre-built alerts in addition to what you would normally get by installing the .NET agent.

A recovery period of time begins when a data source enters a non-breaching state after being in a breaching state. The recovery period is set in the condition's threshold. An incident will close when a source remains in a non-breaching state and the recovery period time has elapsed. If the data source enters a breaching state before the time has elapsed, the recovery period clock will reset and the incident won't close.

For distributed tracing, the root span is the first span in a trace. In many cases, the root span duration will represent the duration of the entire trace, or be very close to it.

However, for more complex, modern systems that use a lot of asynchronous, non-blocking processes, this will not be true. For those systems, the root span's duration may be significantly less than the duration of the trace.

The term RPM usually refers to the number of requests per minute your application receives from users. This is usually the same as CPM (calls per minute).

Historically, some New Relic monitoring solutions, like and browser monitoring, used to contain RPM in the URL; for example, https://rpm.newrelic.com. This language use originally referred to Rails performance management because the first iteration of New Relic monitored Ruby on Rails applications. We monitor many more languages and systems than just Ruby now.

In the context of alerting, a runbook contains standard procedures and operations typically used by system administrators, network operations staff, and other personnel to handle outages, alert incidents, and other situations. If your organization stores runbook instructions as URLs, you can link this information to an alerts policy so your personnel has easy access to this information when an incident breaches the defined policy thresholds.

In the context of alerting, the signal is the stream of telemetry data that's watched and alerted on. You use a NRQL query to define a signal.

A unique signal is generated when the condition sees a unique stream of data that matches the NRQL query. Queries can contain a FACET clause in order for a single condition to generate multiple discrete signals; one for each matching facet. For more information, see NRQL alert conditions.

In the context of alerting, a target is a resource or component monitored by a New Relic monitoring tool that has been identified in an alert condition. When the data source for that target crosses the defined critical threshold, we open an incident. Depending on your policy's incident preference setting, alerts may create an incident record and send notifications through the defined channels. See also entity.

Thresholds are alert condition settings that define an incident. Threshold values include the value a data source must pass to trigger an incident and the time-related settings that define an incident; for example:

Passing a certain value for at least x minutes
Passing a certain value only once in x minutes
While the data source passes a certain value, a degradation period starts. Likewise, when that data source stops passing a certain value, a recovery period starts. The durations of these two time periods are defined in the alert condition threshold settings.
Thresholds have a required critical (red) threshold and an optional warning (yellow) threshold. In the UI, the entity's health status indicator will change to yellow or red when a threshold has been crossed and an incident will open.
For more information, see Define thresholds. For an explanation of how thresholds relate to other basic alerts concepts, see Concepts and workflow.

A tier can refer to how New Relic categorizes or visualizes the various agent language ecosystems that we support. For example:

In APM, the color-coded categories that appear on your app's main Overview chart show response time spent in various functions, processes, or agents as tiers; for example, request queuing, garbage collection, Middleware, JVMs, etc.
In New Relic labels, TIER can be used to define or classify the client-server architecture; for example, frontend and backend tiers.
"Tier" may sometimes be used to refer to our pricing editions.

A transaction is defined as one logical unit of work in an application. This term primarily refers to server-side transactions monitored by APM. For more information, see documentation about web transactions and non-web transactions.

The term transaction is also sometimes used in browser monitoring. In that case, it primarily refers to activity beginning with a browser-side web request and ending with a complete page load.

In the context of APM, web external describes the portion of time spent in web transactions communicating with external services from within the code of the service you're monitoring. That time can be a call to a third party (a payment provider, for example) or it could be a call to another microservice within your own company. Web external time demonstrates how performance is impacted by calls over a network to code executing outside the application you're measuring.

account family

account switcher

agent

aggregation delay

aggregation function

aggregation method

aggregation timer

aggregation window

AI

alert

alert condition

alert evaluation

alert policy

anomaly

apdex

apdex_f

apdex_t

API (application programming interface)

APM

application

application ID

application name

attribute

availability monitoring

browser

Browser monitoring

background external

child account

cloud-based integration

collector

command line interface (CLI)

condition ID

conditions

container

CPM (calls per minute)

CPU burn

custom attribute

custom dashboard

custom event

custom instrumentation

custom metric

data collector

metrics and events

degradation period

dependencies

destinations

dimensional metric

distributed tracing

Docker

downtime

entity

event

expected error

external service

facet

Flex

framework

golden metrics

harvest cycle

health status indicator

host

ignored error

incident

Infinite Tracing

Infrastructure monitoring

Insights

instance ID

instrumentation

integration

interaction

interaction trace

inventory data

issue

key transaction

log

log monitoring

logs in context

New Relic Lookout

master account