---
title: Glossary of New Relic terms
source: https://docs.newrelic.com/docs/new-relic-solutions/get-started/glossary
---

Whether you're considering New Relic or you're already using our capabilities, this glossary of common terminology can help. And if you're looking to get started, see [Get started with New Relic](https://docs.newrelic.com/docs/new-relic-solutions/get-started/intro-new-relic).

**account**

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](https://docs.newrelic.com/docs/accounts/accounts-billing/account-structure/new-relic-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.

**account family**

A New Relic organization can have one or more [accounts](#account).

An "account family" refers to a parent account and the children accounts under it: in other words, a group of related accounts tied together by billing.

**account switcher**

![The account switcher lets you switch between accounts.](https://docs.newrelic.com/images/accounts_screenshot-crop_account-switcher.webp "The account switcher")

If you have access to more than one account in a multi-account [organization](https://docs.newrelic.com/docs/accounts/accounts-billing/account-structure/new-relic-account-structure), you can use the account switcher to switch between accounts. It's located in the top right of the [New Relic home page](https://one.newrelic.com) and some other entity list views.

For more on factors that affect access to accounts, see [Factors affecting access](https://docs.newrelic.com/docs/accounts/accounts-billing/account-structure/factors-affecting-access-features-data).

To find account settings, use the [user menu](#user-menu).

**agent**

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 APM agents, an infrastructure agent, a browser monitoring agent, and mobile monitoring agents. The various technologies that our agents integrate with are just some of [our many integrations](https://newrelic.com/instant-observability).

For more information, see:

-   [New Relic Instant Observability](https://newrelic.com/instant-observability)
-   [Install agents](https://docs.newrelic.com/docs/agents/manage-apm-agents/installation/install-agent)

**aggregation delay**

For our [alerting feature](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/get-started/choose-your-aggregation-method), this refers to the length of time in seconds to wait for the aggregation window to fill with data. Required when using `aggregation_method` types `CADENCE` or `EVENT_FLOW`.

**aggregation function**

In the context of NRQL alerts, you can use [NRQL functions](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/nrql-syntax-clauses-functions), such as `sum()`, `average()`, or `latest()` to choose how the data points in an [aggregation window](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/get-started/choose-your-aggregation-method) should be processed into a single data point. The single aggregated data point is what's passed through the alert evaluation process.

**aggregation method**

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](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/get-started/choose-your-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.

**aggregation timer**

In the context of [New Relic alerts](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview), this is the length of time in seconds to wait after each data point is received, to ensure the entire batch is processed. Required when using `EVENT_TIMER` `aggregation_method` type.

**aggregation window**

In the context of [New Relic alerts](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview), streaming alerts gathers data together into specific amounts of time. These windows of time are customizable.

Data points are collected together based their timestamps and reported as a batch. The customizable aggregation window provides greater flexibility and fewer false alert events when alerting on irregular or less frequent data points.

**AI**

AI, or artificial intelligence, refers to computer systems that can understand, learn, and perform tasks that normally require human intelligence. At New Relic, when we say AI, we mean the layer of your environment that uses a large language model (LLM) to generate a response (or make a decision) based on end-user prompts.

**alert**

An **alert** communicates an event or alert event that designated personnel can track through [alerts](https://docs.newrelic.com/docs/alerts/new-relic-alerts-beta/getting-started/alerting-new-relic).

For an explanation of how basic alerts concepts are related, see [Concepts and workflow](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview/#concepts-terms).

**alert condition**

An **alert condition** (or **condition**), identified by its unique numeric `condition_id`, contains the criteria for creating an alert event. The condition includes the [threshold](#alert-threshold) that is set for a [metric timeslice](https://docs.newrelic.com/docs/data-analysis/metrics/analyze-your-metrics/data-collection-metric-timeslice-event-data#timeslice-data) or a [custom metric](https://docs.newrelic.com/docs/alerts/new-relic-alerts-beta/configuring-alert-policies/define-custom-metrics-alert-condition) over time on a chosen [target](#alert-target).

For an explanation of how a condition relates to other basic alerts concepts, see [Concepts and workflow](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview/#concepts-terms).

**alert evaluation**

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.

**alert policy**

In the context of alerts, an alert policy is a collection of one or more [alert conditions](https://docs.newrelic.com/docs/alerts/new-relic-alerts/defining-conditions/define-alert-conditions), one or more [notification channels](https://docs.newrelic.com/docs/apis/nerdgraph/examples/nerdgraph-api-notifications-channels/), and an [**Alert event preference**](https://docs.newrelic.com/docs/alerts/organize-alerts/specify-when-alerts-create-events) setting.

A condition contained within a policy may open an alert event depending on the [alert event preference settings](https://docs.newrelic.com/docs/alerts/organize-alerts/specify-when-alerts-create-events). 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](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview/#concepts-terms).

**anomaly**

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/)

**apdex**

**Apdex** is an industry-standard way to measure users' satisfaction with the response time of an application or service. New Relic rates each response as **Satisfied**, **Tolerated**, or **Frustrated**, and uses these ratings to calculate an overall user satisfaction score.

For more information, see [Apdex: Measure user satisfaction](https://docs.newrelic.com/docs/site/apdex-measuring-user-satisfaction).

**apdex_f**

The response time above which a transaction are rated **frustrating**. Defaults to four times `apdex_t`.

-   Requests that complete in less than `apdex_t` are rated **satisfied**.
-   Requests that take longer than `apdex_t`, but less than four times `apdex_t` (`apdex_f`), are **tolerated**.
-   Any requests that take longer than `apdex_f` are rated **frustrating**.

    For more information, see [Apdex: Measure user satisfaction](https://docs.newrelic.com/docs/site/apdex-measuring-user-satisfaction).

**apdex_t**

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](https://docs.newrelic.com/docs/site/changing-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](https://docs.newrelic.com/docs/site/apdex-measuring-user-satisfaction).

**API (application programming interface)**

New Relic offers a variety of APIs and SDKs. For more information, see the [introduction to New Relic APIs](https://docs.newrelic.com/docs/apis).

**APM**

New Relic [APM](https://docs.newrelic.com/docs/apm/new-relic-apm/getting-started/introduction-new-relic-apm) (application performance monitoring) provides monitoring of your web or non-web application's performance. APM supports apps using several [programming languages](https://docs.newrelic.com/docs/agents/manage-apm-agents/installation/install-agent#apm-install).

**application**

For New Relic purposes, any program instrumented by New Relic.

**application ID**

Some New Relic solutions assign a monitored application a unique **application ID**, often shortened to **app ID**. When present, this ID is available in the UI. It is also reported as an attribute and can be queried.

For how to determine this, see [Find app ID](https://docs.newrelic.com/docs/accounts/install-new-relic/account-setup/app-id-other-product-ids).

**application name**

The name that New Relic combines with your license key to uniquely identify a particular app. For more information, see [Name your application](https://docs.newrelic.com/docs/agents/manage-apm-agents/app-naming/name-your-application).

**attribute**

**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](https://docs.newrelic.com/docs/using-new-relic/data/understand-data/query-new-relic-data) or by using the [data dictionary](/attribute-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](https://docs.newrelic.com/docs/apm/other-features/attributes/collecting-custom-attributes) to enhance your monitoring.

    For more information about attributes in APM, see [Agent attributes](https://docs.newrelic.com/docs/apm/other-features/attributes/agent-attributes).

**availability monitoring**

See [Types of synthetic monitors](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/getting-started/types-synthetics-monitors).

**browser**

For our end-user browser monitoring solution, see [Browser Monitoring](https://docs.newrelic.com/docs/browser/new-relic-browser/getting-started/introduction-browser-monitoring).

For information on what browsers support New Relic, see [Supported browsers](https://docs.newrelic.com/docs/site/supported-browsers).

**Browser monitoring**

Measures the speed and performance of your end users as they navigate to your site from different web browsers, devices, operating systems, and networks. For more information, see [Introduction to browser monitoring](https://docs.newrelic.com/docs/browser/browser-monitoring/getting-started/introduction-browser-monitoring/).

**background external**

Refers to time spent in calls to [external services](#external-service) from within the [non-web transactions](#non-web-transaction) of a service. See [web external](#web-external).

**child account**

See [parent account](#parent-account).

**cloud-based integration**

New Relic offers cloud-based integrations with providers such as [Amazon Web Services (AWS)](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/getting-started/introduction-aws-integrations), [Microsoft Azure](https://docs.newrelic.com/docs/infrastructure/microsoft-azure-integrations/getting-started/introduction-azure-monitoring-integrations), and [Google Cloud Platform](https://docs.newrelic.com/docs/integrations/google-cloud-platform-integrations/getting-started/introduction-google-cloud-platform-integrations).

**collector**

The component that collects data from New Relic [agents](#agent) 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](https://docs.newrelic.com/docs/apm/new-relic-apm/getting-started/networks). (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](https://docs.newrelic.com/docs/new-relic-one/use-new-relic-one/get-started/introduction-new-relic-one) and by our various REST APIs.

**command line interface (CLI)**

Our [command line interface](https://docs.newrelic.com/docs/new-relic-solutions/build-nr-ui/newrelic-cli) (CLI) is a tool that lets you manage New Relic, including managing and controlling your use of New Relic at scale.

**condition ID**

See [alert condition](#alert-condition).

**conditions**

Use alert conditions to define when and why your team will be notified if your entities aren't working the way you want. With conditions, you establish the criteria for notifications about lag time, code errors, Apdex scores, high CPU usage, and more.

For more information, see [alert events](https://docs.newrelic.com/docs/new-relic-solutions/get-started/glossary#alert-event).

**container**

A container is a standard unit of software that carries all the necessary pieces of code and all of its dependencies in order for your application to run smoothly across a variety of computing environments.

**CPM (calls per minute)**

The number of calls your application receives each minute. This usually corresponds to the number of page views or external connections, and is usually the same as [RPM (requests per minute)](#rpm).

**CPU burn**

The time consumed by code minus the wait time for a transaction. This is the time actually spent processing the transaction. It appears in the New Relic UI at the top of the transaction view for the agents that provide it (Ruby and PHP only).

**custom attribute**

A key-value pair added to a transaction or event in order to gain additional information about it. For more information, see [custom attributes](https://docs.newrelic.com/docs/apm/other-features/attributes/collecting-custom-attributes).

**custom dashboard**

A customizable dashboard with charts and tables that includes data from multiple New Relic data sources. For more information, see [dashboards](https://docs.newrelic.com/docs/dashboards/new-relic-one-dashboards/get-started/introduction-new-relic-one-dashboards).

**custom event**

An [event](#event), in New Relic terms, is a data object with attached [attributes](#attribute). New Relic reports default event types, like `Transaction` and `TransactionError`. You can also create your own events. Events can be [queried](https://docs.newrelic.com/docs/using-new-relic/data/understand-data/query-new-relic-data), and are used in some other features.

You can generate custom events with [APM agents](https://docs.newrelic.com/docs/data-apis/custom-data/custom-events/apm-report-custom-events-attributes), the [browser monitoring agent](https://docs.newrelic.com/docs/data-apis/custom-data/custom-events/report-browser-monitoring-custom-events-attributes), the [mobile monitoring agents](https://docs.newrelic.com/docs/data-apis/custom-data/custom-events/report-mobile-monitoring-custom-events-attributes), and via the [Event API](https://docs.newrelic.com/docs/data-apis/ingest-apis/event-api/introduction-event-api). Alternatively, you can add [custom attributes](#custom-attribute) to some existing default New Relic events.

**custom instrumentation**

**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](#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](https://docs.newrelic.com/docs/features/custom-instrumentation).

**custom metric**

[Metric timeslice data](#metric) that is manually recorded via an API call. **Custom metrics** allow you to record arbitrary metrics; for example, timing or computer resource data. All custom metric names must be prefixed with `Custom/`. For more information, see [Custom metrics](https://docs.newrelic.com/docs/features/custom-metrics).

Not to be confused with [custom instrumentation data](#custom-instrumentation-data).

**data collector**

See [collector](#collector).

**metrics and events**

In the **Metrics and events** UI, you can access, query and customize your data, create visualizations, and make connections between your services in a consistent and curated experience.

For more on this, see [Introduction to metrics and events](https://docs.newrelic.com/docs/query-your-data/explore-query-data/data-explorer/introduction-data-explorer).

**degradation period**

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 alert event 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 alert event does not open.
-   If your alert condition threshold is configured as `at least once in`, the degradation period always lasts a single minute.

**dependencies**

A dependency is the code that your application depends on in order to function. New Relic provides a list of all the applications, services, databases, and hosts we can tell are connected to an entity. On the [**Dependencies** UI page](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/ui-data/explore-downstream-dependencies-new-relic-one), you can find an entity's upstream and downstream dependencies, and the paths to explore them.

**destinations**

In the context of alerting, [destinations](https://docs.newrelic.com/docs/alerts-applied-intelligence/notifications/destinations) are where we send notifications about your data. A destination is a unique identifier for a third-party system that you use.

Destination settings contain the connection details to integrate with third-party systems and can be used across a variety of tools in New Relic.

**dimensional metric**

A **dimensional metric** is a metric that has multiple [attributes](#attribute), also known as dimensions. At New Relic, we report dimensional metrics using the [`Metric` data type](https://docs.newrelic.com/docs/using-new-relic/data/understand-data/new-relic-data-types#dimensional-metrics). For more on other metric data types, see [Metric data](https://docs.newrelic.com/docs/using-new-relic/data/understand-data/new-relic-data-types#metrics).

**distributed tracing**

Distributed tracing is a method of monitoring requests as they flow through various cloud environments. Distributed tracing tracks a request by tagging it with a unique identifier. This allows your team to have a real-time understanding of the interactions taking place within your entities.

**Docker**

An open platform for distributed applications, which allows you to assemble multi-container portable apps. Infrastructure monitoring includes [integrated Docker monitoring](https://docs.newrelic.com/docs/infrastructure/new-relic-infrastructure/data-instrumentation/docker-instrumentation-infrastructure). For more on Docker, see the [Docker website](http://www.docker.com/).

**downtime**

The period of time when customers cannot access your site and your app is not reporting to New Relic. For more information, see [Synthetic monitoring](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/getting-started/new-relic-synthetics) and [Types of synthetic monitors](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/getting-started/types-synthetics-monitors).

**entity**

In New Relic, an **entity** is anything we can identify that has data you can monitor. An entity can be something you monitor directly, like applications and microservices, or indirectly, like data centers.

For more on this, see [What are entities?](https://docs.newrelic.com/docs/new-relic-one/use-new-relic-one/core-concepts/what-entity-new-relic)

**event**

In the software industry, events can be thought of as simply “things that occur in a system.” For example, changing a server setting is an event. Another example: a website user clicking a mouse.

Some events generate a stored record, and that record is typically also called an event.
To learn how New Relic uses events, see [New Relic data types](https://docs.newrelic.com/docs/data-apis/understand-data/new-relic-data-types/#event-data).

**expected error**

An expected error is a common error that you don't want to affect your Apdex score or error rate. For more information, see [Manage errors in APM](https://docs.newrelic.com/docs/agents/manage-apm-agents/agent-data/manage-errors-apm-collect-ignore-mark-expected).

**external service**

An external service is a [service](#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`.

**facet**

A facet helps your team compare information that has many variables. You can query New Relic data in NRQL and use facets to segment the displayed data. For example, if you want to know where your CPU data is being used, you can segment your CPU data by the hostname facet:

`SELECT average(cpuPercent) FROM SystemSample FACET hostname`

**Flex**

[New Relic Flex](https://docs.newrelic.com/docs/introduction-new-relics-flex-integration) is an application-agnostic, all-in-one infrastructure [integration](https://docs.newrelic.com/docs/infrastructure/host-integrations/get-started/introduction-host-integrations). 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.

**framework**

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?](http://stackoverflow.com/questions/148747/what-is-the-difference-between-a-framework-and-a-library "Link opens in a new window").

New Relic automatically instruments many common frameworks. For more about the frameworks New Relic supports, browse our solutions on [Instant Observability](https://newrelic.com/instant-observability).

**golden metrics**

The most important metrics for a given entity, use case, or technology. Golden metrics can include [golden signals:  latency, traffic, errors, and saturation](https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals).

**harvest cycle**

The period of time between each connection from a New Relic [agent](#agent) to the [collector](#collector). Between **harvest cycles**, an agent collects and caches data. At the end of the cycle an agent reports those data to the collector, then begins a new harvest cycle.

**health status indicator**

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)](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/understand-technical-concepts/view-entity-health-status-find-entities-without-alert-conditions) 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 alert events.

Exceptions to the above-mentioned color palette:

-   Learn about [service map colors](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/ui-data/service-maps/how-use-service-maps/#alerts)
-   Our REST API (v2) uses `orange` instead of `yellow` for the [application's health and reporting status](https://docs.newrelic.com/docs/apis/rest-api-v2/application-examples-v2/application-reporting-health-status-v2).

**host**

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.

**ignored error**

An error that you have told an APM agent not to report to the [collector](#collector). For more information, see [Manage errors in APM](https://docs.newrelic.com/docs/agents/manage-apm-agents/agent-data/manage-errors-apm-collect-ignore-mark-expected).

**alert event**

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

You can view detailed information from the [**Alert events** pages](https://docs.newrelic.com/docs/alerts/alert-event-management/view-alert-event-details) in the user interface. You can also [select your preference](https://docs.newrelic.com/docs/alerts/organize-alerts/specify-when-alerts-create-events/) for how we roll up alert events.

For an explanation of how an alert event relates to other basic alerts concepts, see [Concepts and workflow](https://docs.newrelic.com/docs/alerts/overview/#concepts-terms).

**Infinite Tracing**

Infinite Tracing is a fully managed distributed tracing service that observes 100% of your application traces, then provides actionable data so you can solve issues faster.

For more information, see [/docs/understand-dependencies/distributed-tracing/get-started/how-new-relic-distributed-tracing-works](https://docs.newrelic.com/docs/understand-dependencies/distributed-tracing/get-started/how-new-relic-distributed-tracing-works).

**Infrastructure monitoring**

By connecting changes in host performance to changes in your configuration, [infrastructure monitoring](https://docs.newrelic.com/docs/infrastructure/new-relic-infrastructure/getting-started/introduction-new-relic-infrastructure) 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**

Insights was a legacy New Relic product (now decommissioned) that managed custom event reporting, querying, and charting. These capabilities are now core, integrated platform features rather than a separate product.

To learn more about querying and custom events:

-   [Event API](https://docs.newrelic.com/docs/telemetry-data-platform/ingest-apis/introduction-event-api) for reporting custom events

-   [Query and chart data](https://docs.newrelic.com/docs/query-your-data/explore-query-data/query-builder/introduction-query-builder)

    For historical reasons, the word "Insights" is still used in some places. For example:

-   For New Relic organizations on our [original pricing model](https://docs.newrelic.com/docs/accounts/original-accounts-billing/original-product-based-pricing/overview-changes-pricing-user-model/#pricing-plans), 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](https://docs.newrelic.com/docs/agents/java-agent/configuration/java-agent-configuration-config-file/#Custom_Events).

-   There is an API key called the [Insights insert key](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#insights-insert-key).

**instance ID**

Each instance identified by New Relic is assigned a unique **instance ID**. Instance IDs are most commonly found for JVMs (Java Virtual Machines), but can exist for each agent. This ID is used to uniquely identify it, and to retrieve data about that instance via the API. For more information, see the REST API's [List instance IDs](https://docs.newrelic.com/docs/apis/rest-api-v2/requirements/list-application-id-host-id-instance-id#locating_instance_id).

**instrumentation**

The collection of [data](https://docs.newrelic.com/docs/data-analysis/metrics/analyze-your-metrics/data-collection-metric-timeslice-event-data) from an application or host. When New Relic instruments a [framework](#framework), it detects the methods and calls used by that framework, and intelligently groups them together.

**integration**

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](https://newrelic.com/instant-observability/).

**interaction**

In our [mobile monitoring](#nr-mobile), an **interaction** is a specific code path initiated by a user interaction (usually a button press). An interaction is the mobile equivalent of a [transaction](#transaction), and like a transaction an interaction can be [traced](#interaction-trace) and monitored.

You can see much of the data included in an interaction in the [BrowserInteraction](/attribute-dictionary/?event=BrowserInteraction) event.

**interaction trace**

An **interaction trace** is a complete picture of a single [interaction](#interaction). With interaction traces, New Relic gives you much deeper visibility into a single slow interaction, which can help you understand a broader problem. Interaction traces are the mobile equivalent of a [transaction trace](#transaction-trace). For more information, see [Creating interactions (iOS)](https://docs.newrelic.com/docs/mobile-monitoring/mobile-sdk-api/new-relic-mobile-sdk-api/working-ios-sdk-api#interactions) and [Creating interactions (Android)](https://docs.newrelic.com/docs/mobile-monitoring/mobile-sdk-api/new-relic-mobile-sdk-api/working-android-sdk-api#creating).

**inventory data**

**Inventory data** is information about the status or configuration of a service or host. Examples of inventory data include:

-   Configuration settings
-   Name of the host the service is on
-   AWS region
-   Port being used

    For more information, see [Understand and use data](https://docs.newrelic.com/docs/integrations/new-relic-integrations/getting-started/understand-use-data-infrastructure-integrations#inventory-data).

**issue**

In the context of alerting, an **issue** is a problem in your system that needs attention. An issue is made up of one or more [alert events](https://docs.newrelic.com/docs/new-relic-solutions/get-started/glossary#alert-event) and anomalies we've correlated through machine learning or other means. You can receive notifications when issues are created, acknowledged, or closed.

For more information, see [Alerts concepts & workflow](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview/#concepts-terms).

**key transaction**

In APM, a key transaction is a [web transaction](#web-transaction) that the user has marked as particularly important; for example, key business events (such as signups or purchase confirmations), or transactions with a high performance impact (such as searches). Key transactions have their own pages in the UI and other customized values. For more information, see [Key transactions](https://docs.newrelic.com/docs/transactions-menu/key-transactions).

**log**

A **log** is a message about a system used to understand the activity of the system and to diagnose problems. For more information on how we use log data, see [log management](https://docs.newrelic.com/docs/logs/new-relic-logs/get-started/introduction-new-relic-logs).

**log monitoring**

Our [log management and monitoring](https://docs.newrelic.com/docs/logs/enable-log-management-new-relic/enable-log-monitoring-new-relic/enable-log-management-new-relic) features give you the tools to collect, process, explore, visualize, and alert on your log data using your existing log forwarder. With all of your log data in one place, you'll be able to make better decisions, detect and resolve problems more quickly, and see your logs in context to troubleshoot faster.

**logs in context**

[Logs in context](https://docs.newrelic.com/docs/logs/enable-log-management-new-relic/configure-logs-context/configure-logs-context-apm-agents) allows your log data to be seen in other New Relic platform experiences.

**New Relic Lookout**

[New Relic Lookout](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/core-concepts/new-relic-explorer-view-performance-across-apps-services-hosts) provides an intuitive view of entities that are deviating from normal behavior, using circle visualization. Color indicates severity, and size of circles conveys the scale of recent changes. You don't need to configure anything: New Relic Lookout automatically compares performance within the last five minutes against the previous hour.

**master account**

See [parent account](#parent-account).

**metric**

In the software monitoring industry, a metric means a numeric measurement of an application or system. To learn how New Relic defines and uses metrics, see [New Relic data types](https://docs.newrelic.com/docs/data-apis/understand-data/new-relic-data-types/).

**metric timeslice**

New Relic reports [metrics in several ways](https://docs.newrelic.com/docs/telemetry-data-platform/understand-data/new-relic-data-types/#metrics). One variety of metric data is called **metric timeslice data**. For more about this type of data, see [New Relic data types](https://docs.newrelic.com/docs/data-apis/understand-data/new-relic-data-types).

**metric grouping issue**

A **metric grouping issue** occurs when an account sends too many differently named [metric timeslice data points](#metric) 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](https://docs.newrelic.com/docs/features/metric-grouping-issues).

**Synthetics Job Manager**

The software that accepts [synthetic monitor](#monitor) jobs from a [private location](#private-location). A Synthetics Job Manager can be run with Docker on a host or VM, or in a Kubernetes cluster. For more information, see [Private locations overview](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/private-locations/private-locations-overview-monitor-internal-sites-add-new-locations).

**mobile monitoring**

New Relic [mobile monitoring](https://docs.newrelic.com/docs/mobile-apps/new-relic-mobile) allows you to monitor and manage the performance of your mobile apps on Android, iOS, tvOS, and other systems. Mobile monitoring provides end-to-end details, including crashes, throughput, HTTP requests, error traces, and more.

**monitor**

For our synthetic monitoring, a **monitor** ensures your website or API endpoint is available. For more information, see [Adding and editing monitors](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/using-monitors/adding-editing-monitors).

**namespace**

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](https://docs.newrelic.com/docs/data-apis/manage-data/manage-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.

**New Relic Navigator**

[New Relic Navigator](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/core-concepts/new-relic-explorer-view-performance-across-apps-services-hosts) makes it easy to explore large numbers of entities in one view. Navigator displays the entire estate of your system in a highly dense honeycomb view with traffic light colors based on [alerts](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/learn-alerts/alerts-concepts-workflow/).

**NerdGraph**

[NerdGraph](https://docs.newrelic.com/docs/apis/nerdgraph/get-started/introduction-new-relic-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](https://docs.newrelic.com/docs/apis/nerdgraph/get-started/nerdgraph-explorer), or go right to the [NerdGraph API explorer](https://api.newrelic.com/graphiql).

**New Relic**

For more information, see [Introduction to New Relic](https://docs.newrelic.com/docs/new-relic-one/use-new-relic-one/get-started/introduction-new-relic-one).

**New Relic catalog**

Our catalog is a collection of applications built on the New Relic platform. The catalog includes custom apps we've built, public open source apps, and any apps that you buid.

You can browse the catalog on [New Relic](https://one.newrelic.com/launcher/nr1-core.home?pane=eyJuZXJkbGV0SWQiOiJucjEtY29yZS5ob21lLXNjcmVlbiJ9&overlay=eyJuZXJkbGV0SWQiOiJucjEtY2F0YWxvZy5hcHAtZGlyZWN0b3J5In0=).

**NRQL (New Relic query language)**

[NRQL](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/nrql-syntax-clauses-functions) is a query language, similar in form to SQL, that allows you to query the data stored in your New Relic account.

**non-web transaction**

APM identifies [transactions](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/transactions-new-relic-apm) as either web or non-web. When New Relic does not detect a transaction was initiated by a web request, this is called a non-web transaction. For more information, see [Background processes and other non-web transactions](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/monitor-background-processes-other-non-web-transactions).

**notification**

In the context of alerting, a notification is a message sent when an alert event opens, is acknowledged, or closes. The [type of notification](https://docs.newrelic.com/docs/alerts/get-notified/destinations) is defined by the [alert policy's notification channel](https://docs.newrelic.com/docs/alerts/new-relic-alerts-beta/managing-notification-channels/add-or-remove-policy-channels).

For an explanation of how notifications relate to other basic alerts concepts, see [Concepts and workflow](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview/#concepts-terms).

**notification channel**

In the context of alerting, a notification channel is where we send a notification when an alert event opens, is acknowledged, or closes. Available channels include [email, mobile push notifications, webhooks, and more](https://docs.newrelic.com/docs/alerts/get-notified/destinations).

**obfuscating**

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.

**on-host integration**

**On-host integrations** refer to integrations that reside on your own servers or hosts and that communicate with our infrastructure agent. For more information, see [Introduction to on-host integrations](https://docs.newrelic.com/docs/infrastructure/host-integrations/getting-started/introduction-host-integrations).

**organization**

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](https://docs.newrelic.com/docs/accounts/accounts-billing/account-structure/new-relic-account-structure).
-   We sometimes use "organization" in a general way to refer to a business or non-profit entity.

**page load timing**

With **page load timing**, New Relic monitors the full load time for end-user browsers. New Relic [application agents](#agent) 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](https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/page-load-timing-process).

**parameter**

Deprecated term; see [attribute](#attribute).

**parent account**

New Relic organizations can have a parent/child account structure and would be relevant for some features for organizations. 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.](https://docs.newrelic.com/docs/accounts/accounts-billing/account-structure/new-relic-account-structure)

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

**permalink**

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](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/ui-data/basic-ui-features/#share).

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.

**pinger**

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](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/getting-started/new-relic-synthetics). 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](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/getting-started/types-synthetics-monitors).

**policy**

In the context of alerting, an alert policy is a bucket for similar alert conditions so that you can see them all in one place. So, if your team wants to examine all of the conditions for your Java application, you need to create a policy to contain those conditions.

For more information, see [Alerts concepts and workflow](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/learn-alerts/alerts-concepts-workflow).

**polling interval (AWS)**

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](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/troubleshooting/metric-data-delays-amazon-aws-integrations).

**PPM (pages per minute)**

The number of pages per minute your application serves. This is usually used in the context of [browser monitoring](https://docs.newrelic.com/docs/browser/browser-monitoring/getting-started/introduction-browser-monitoring) or [mobile monitoring](https://docs.newrelic.com/docs/mobile-monitoring/new-relic-mobile/get-started/introduction-mobile-monitoring).

**private location**

A synthetic monitor feature that allows you to run synthetic [monitors](#monitor) from within your own systems by creating [private minions](#minion). **Private locations** allow you to extend your synthetic coverage to new geographical locations, and to monitor websites behind your firewall such as an intranet site. For more information, see [Private locations overview](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/private-locations/private-locations-overview-monitor-internal-sites-add-new-locations).

**quickstart**

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

-   Additional dashboards (in addition to our curated dashboards) accessible from the **Dashboards** UI
-   Pre-built alerts

    Quickstarts are featured on our [Instant Observability pages](https://newrelic.com/instant-observability): for example, [this page includes a quickstart for .NET](https://newrelic.com/instant-observability/dotnet) that gets you an extra dashboard and pre-built alerts in addition to what you would normally get by installing the .NET agent.

**recovery period**

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 alert event 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 alert event won't close.

**regex**

Shorthand for regular expressions. A string of characters and operators that, when used in tandem with a programming language, searches a chunk of text for patterns. For example, if you wanted to locate any social security number in your logs, you could create a regex that searches your logs for a number pattern that follows a `{3 digit-2 digit-4 digit}` pattern.

**response time**

The duration of time between a request for service and a response. These kinds of charts are used for our APM monitoring and browser monitoring. For more information, see [Response time](https://docs.newrelic.com/docs/data-analysis/user-interface-functions/view-your-data/response-time).

**rollup**

In the context of APM, this usually refers to using the same application name for multiple applications. This allows you to combine data in APM, either from multiple applications, or from multiple instances of an application. For more information, see [Rolling up app data](https://docs.newrelic.com/docs/apm/new-relic-apm/installation-configuration/using-multiple-names-app#rollup).

**root span**

For [distributed tracing](https://docs.newrelic.com/docs/apm/distributed-tracing/getting-started/introduction-distributed-tracing), the **root span** is the first [span](#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.

**RPM**

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

Historically, some New Relic monitoring solutions, like APM 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**](https://stackoverflow.com/questions/5252561/rails-new-relic-what-does-rpm-mean) because the first iteration of New Relic monitored Ruby on Rails applications. We monitor many more languages and systems than just Ruby now.

**RUM (real user monitoring)**

See [browser monitoring](https://docs.newrelic.com/docs/browser/browser-monitoring/getting-started/introduction-browser-monitoring).

**runbook**

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 alert events, 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](https://docs.newrelic.com/docs/alerts/create-alert/condition-details/provide-runbook-instructions-alert-activity) when an alert event breaches the defined policy thresholds.

**SAML (Security Assertion Markup Language)**

**SAML** is an XML-based data format for sharing authentication data between two parties. For information about our SAML features, see [SAML SSO](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/introduction-saml-scim).

**Selenium**

**Selenium** is an open-source browser testing suite. [Synthetic monitoring](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/getting-started/new-relic-synthetics) uses Selenium to test monitored websites with real browsers. For more information, see [monitor types](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/using-monitors/adding-editing-monitors#setting-type).

**service**

A **service** is a cluster of runtime server processes that accomplish a particular task, usually service requests. Unlike an application, a service is not usually invoked by a human. Sometimes, though, "application" and "service" are used interchangeably.

We offer [a large number of agents and integrations](https://newrelic.com/instant-observability) that allow you to report data from your services.

**signal**

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](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-nrql-alert-conditions).

**signal filter**

When we receive data and it's routed to the [streaming alerts platform](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/understand-technical-concepts/streaming-alerts-key-terms-concepts), your NRQL `WHERE` clause will filter the data coming in. The filtered streaming data is what's evaluated for loss of signal alert events, for example.

**span**

In a distributed trace, a **span** is a "named, timed operation representing a contiguous segment of work in that trace" (from [OpenTracing.io](https://opentracing.io/docs/overview/spans/) definition).

For [distributed tracing](https://docs.newrelic.com/docs/apm/distributed-tracing/getting-started/introduction-distributed-tracing), spans are displayed in the distributed tracing UI, and the data type [`Span`](https://docs.newrelic.com/docs/apm/distributed-tracing/ui-data/distributed-tracing-attributes) is available for [querying](https://docs.newrelic.com/docs/using-new-relic/data/understand-data/query-new-relic-data).

See also [root span](#root-span).

**SSL certificate**

**SSL certificates** encrypt data that is being transmitted. While New Relic refers to security certificates as SSL because it is a more commonly used term, all certificates adhere to industry standards for secure encryption in transit.

**SSO (single sign on)**

**SSO** (single sign on) allows you to manage user authentication in New Relic using an external SSO provider. For more information, see [SAML SSO](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/introduction-saml-scim).

**streaming algorithm**

In the context of alerting, this is what determines when the data in an [aggregation window](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/get-started/choose-your-aggregation-method) is processed. The streaming algorithm uses your server's clock time and the aggregation window size to trigger the alert evaluation process.

**sub-accounts**

See [master account](#parent-account).

**Synthetic monitoring**

[Synthetic monitoring](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/getting-started/new-relic-synthetics) allows you to monitor your website or API endpoint via automated, scriptable tools. Use free ping monitor to ensure your website is accessible, or expand your monitoring with browser monitors, which test your website with real browsers. Go further with scripting, to script browsers or API monitors for sophisticated testing.

**target**

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](https://docs.newrelic.com/docs/alerts/create-alert/create-alert-condition/alert-conditions/). When the data source for that target crosses the defined critical threshold, we open an alert event. Depending on your policy's [alert event preference](https://docs.newrelic.com/docs/alerts/organize-alerts/specify-when-alerts-create-events) setting, alerts may create an alert event record and send notifications through the defined channels. See also [**entity**](#entity).

**tag**

Tags are key:value metadata added to monitored apps, hosts, dashboards, and other entities to help you organize your data and make it easier to use. For details, see [Tags](https://docs.newrelic.com/docs/new-relic-one/use-new-relic-one/core-concepts/tagging-use-tags-organize-group-what-you-monitor).

**telemetry**

When you're using New Relic, you're gathering telemetry data. With New Relic, you monitor your systems and collect data in the form of [metrics, events, logs, and traces](https://docs.newrelic.com/docs/data-apis/understand-data/new-relic-data-types). New Relic then stores that collected data in our servers, which you can access and analyze through your dashboards.

**thresholds**

**Thresholds** are alert condition settings that define an alert event. Threshold values include the value a data source must pass to trigger an alert event and the time-related settings that define an alert event; 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](#degradation-period) starts. Likewise, when that data source stops passing a certain value, a [recovery period](#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](#health-status) indicator will change to yellow or red when a threshold has been crossed and an alert event will open.

    For more information, see [Define thresholds](https://docs.newrelic.com/docs/alerts/new-relic-alerts-beta/configuring-alert-policies/define-thresholds-trigger-alert). For an explanation of how thresholds relate to other basic alerts concepts, see [Concepts and workflow](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview/#concepts-terms).

**throughput**

**Throughput** is a measurement of user activity for a monitored application. APM throughput and browser monitoring throughput are measured in different ways:

-   APM: requests per minute (RPM)
-   Browser: page views per minute (PPM)

**tier**

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](https://docs.newrelic.com/docs/apm/applications-menu/monitoring/apm-overview-page) 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](https://docs.newrelic.com/docs/data-analysis/user-interface-functions/labels-categories-organize-your-apps-servers), `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](https://newrelic.com/pricing).

**time picker**

Typically, New Relic UI experiences show data for the past 30 minutes, ending at the current moment in time. To change the time window, you can use the [time picker](https://docs.newrelic.com/docs/query-your-data/explore-query-data/dashboards/manage-your-dashboard/#dash-time-picker) in the upper right section of the UI.

**time range**

A **time range** can refer to a length of time selected in the New Relic UI. New Relic displays a time range depending on the range you select using the [time picker](#time-picker).

**timeslice data**

See [metric timeslice data](#metric).

**trace**

A **trace** is a description of how a request travels through a system. Trace data helps you understand the performance of your system and diagnose problems. For more information on how we use trace data, see [New Relic data types](https://docs.newrelic.com/docs/using-new-relic/data/understand-data/new-relic-data-types#trace-data).

**traffic light**

See [health status](#health-status).

**transaction**

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](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/transactions-new-relic-apm) and [non-web transactions](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/monitor-background-processes-other-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.

**transaction trace**

In New Relic APM, a **transaction trace** refers to a complete picture of a single [transaction](#transaction), down to the database queries and exact invocation patterns. With transaction traces, New Relic gives you much deeper visibility into a single slow transaction, which can help you understand a broader problem. For more information, see [Transaction traces](https://docs.newrelic.com/docs/apm/transactions/transaction-traces/transaction-traces).

**UI**

The New Relic user interface. For more information, see [Standard page functions](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/introduction-new-relic-platform).

**user**

For details about New Relic users and how to manage them, see [User management](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/introduction-managing-users).

**user menu**

The user menu is in the bottom left of the New Relic platform and is where your organization- and account-related settings can be accessed. For more information, see [Account settings](https://docs.newrelic.com/docs/accounts/accounts-billing/general-account-settings/intro-account-settings).

**UTC**

**Universal Time Coordinated (UTC)**, or Coordinated Universal Time, is a standard timestamp for synchronizing time around the world.

**value function (metrics)**

The numeric value obtained from [metric timeslice data](#metric); for example, an average, minimum, maximum, total, sample size, etc.

**violation (deprecated)**

This term has been replaced in the UI with [alert event](https://docs.newrelic.com/docs/new-relic-solutions/get-started/glossary#alert-event).

**web external**

In the context of APM, **web external** describes the portion of time spent in [web transactions](#web-transaction) communicating with [external services](#external-service) 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.

**web transaction**

A **transaction** is defined as one logical unit of work in an application. This term primarily refers to server-side transactions monitored by APM.

Web transactions are initiated with an HTTP request. For most organizations, these represent customer-centric interactions and thus are the most important transactions to monitor. For more information, see [Web transactions](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/transactions-new-relic-apm) and [Non-web transactions](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/monitor-background-processes-other-non-web-transactions).

**WebDriverJS**

**WebDriver** is a [Selenium](#selenium) component, used to control synthetic [scripted browsers](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/scripting-monitors/writing-scripted-browsers). Specifically, synthetic monitoring uses WebDriverJS, a Node.js-based flavor of Selenium. For more information, see [Writing scripted browsers](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/scripting-monitors/writing-scripted-browsers) and [Scripted browser examples](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/scripting-monitors/scripted-browser-examples).

**workflows**

Workflows are how you route alert notifications to the right people when problems occur. To make troubleshooting easier, you can add queries to workflows to automatically enrich your notifications with more info around the alert events.

For more information, see [Workflows](https://docs.newrelic.com/docs/alerts/get-notified/alert-event-workflows).

**workload**

Workloads let you group entities that work together to provide a specific business value. Then you can easily monitor availability and resource consumption for what's relevant to you. For example, you could make a workload with all the hosts that make up a data center.

For more information, see [Intro to workloads](https://docs.newrelic.com/docs/new-relic-solutions/new-relic-one/workloads/workloads-isolate-resolve-alert-events-faster).