--- title: Transactions in New Relic's APM source: https://docs.newrelic.com/docs/apm/transactions/intro-transactions/transactions-new-relic-apm --- The word **transaction** can have several different meanings in the software industry. This document explains how the term is used by New Relic and how transactions are reported. ## What is a transaction? [#txn-defined] At New Relic, a **transaction** is defined as one logical unit of work in a software application. Specifically, it refers to the function calls and method calls that make up that unit of work. For APM, it will often refer to a **web transaction**, which represents activity that happens from when the application receives a web request to when the response is sent. When you install APM in a [supported system](https://docs.newrelic.com/docs/agents/manage-apm-agents/installation/compatibility-requirements-new-relic-agents), it begins automatically reporting web requests and other important functions and methods. To supplement the default level of monitoring, you can set up [custom instrumentation](https://docs.newrelic.com/docs/apm/agents/manage-apm-agents/agent-data/custom-instrumentation/) to report additional transactions. Some frameworks do not have a natural concept of a transaction. In other words, there are no predefined pathways that can easily be recognized or monitored as transactions. To define transactions in such frameworks, you can use [custom instrumentation](https://docs.newrelic.com/docs/apm/agents/manage-apm-agents/agent-data/custom-instrumentation/). ## Types of transactions [#types] Cumulative transaction data appears in APM on the [Transactions page](https://docs.newrelic.com/docs/apm/applications-menu/monitoring/transactions-page). The two main categories of transactions are web and non-web: - **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. - **Non-web**: [Non-web transactions](https://docs.newrelic.com/docs/apm/transactions/intro-transactions/monitor-background-processes-other-non-web-transactions) are not initiated with a web request. They can include non-web worker processes, background processes, scripts, message queue activity, and other tasks. ### Transaction sub-types Our agents have these transaction sub-types: **Go** Doesn't apply. **Java** | Sub-type | Description | | ----------- | ------------------------------------------------------------------------------------------------ | | Custom | The execution of the named custom transaction. Usually recorded via manual instrumentation APIs. | | `framework` | The invocation of a framework that is recognized by the agent. | **.NET** | Sub-type | Description | | ------------ | ----------------------------------------------------------------------------------------------------------------------- | | `Action` | The invocation of the named framework action. Used when the agent is able to identify a framework-specific action name. | | `ASP` | The invocation of an ASP.NET request. | | `Custom` | The execution of the named custom transaction. Usually recorded via manual instrumentation APIs. | | `MonoRail` | The invocation of a MonoRail request. | | `MVC` | The invocation of a MVC request. | | `OpenRasta` | The invocation of an OpenRasta request. | | `StatusCode` | The HTTP status code returned for the transaction. Often used when a more specific transaction sub-type is unavailable. | | `WCF` | The invocation of a WCF request. | | `WebAPI` | The invocation of a WebAPI request. | | `WebService` | The invocation of a WebService request. | **Node.JS** | Sub-type | Description | | -------- | ------------------------------------------------------------------------------------------------ | | Custom | The execution of the named custom transaction. Usually recorded via manual instrumentation APIs. | | Message | Message broker or queue communication. | **PHP** | Sub-type | Description | | ------------ | ----------------------------------------------------------------------------------------------------------------------- | | `Action` | The invocation of the named framework action. Used when the agent is able to identify a framework-specific action name. | | `Custom` | The execution of the named custom transaction. Usually recorded via manual instrumentation APIs. | | `Function` | The invocation of the named function. | | `PHP` | The invocation of a background PHP job. | | `StatusCode` | The HTTP status code returned for the transaction. Often used when a more specific transaction sub-type is unavailable. | | `unknown` | The invocation of an unknown web transaction or background job. | | `URI` | The invocation of the named URI. Usually used when a framework or language level transaction name cannot be determined. | **Python** | Sub-type | Description | | -------- | --------------------------------------------------------------------------------------------------- | | ASGIWeb | WebTransaction from an [ASGI application](https://asgi.readthedocs.io/en/latest/introduction.html). | | Message | Message broker or queue communication. | | WSGIWeb | WebTransaction from a [WSGI application](https://wsgi.readthedocs.io/en/latest/what.html). | **Ruby** | Sub-type | Description | | -------- | ------------------------------------------------------------------------------------------------ | | Custom | The execution of the named custom transaction. Usually recorded via manual instrumentation APIs. | ## Transaction segments [#segments] The individual functions and calls that make up a transaction are called **segments**. For example external service calls and database calls are segments, and both have their own UI pages in APM. The APM [**Transactions** page](https://docs.newrelic.com/docs/apm/applications-menu/monitoring/transactions-page) displays aggregate transaction segment data. - To add segments to a transaction, use [custom instrumentation](https://docs.newrelic.com/docs/apm/agents/manage-apm-agents/agent-data/custom-instrumentation/). - To see the segments of a specific transaction, use [transaction traces](https://docs.newrelic.com/docs/apm/transactions/transaction-traces/introduction-transaction-traces). ## Transaction naming [#naming] For supported frameworks, transaction names can come from various sources, such as the name given to the transaction by the framework, function names detected during the transaction, or a web request's URL. For transactions that produce many names with a similar format, we consolidate those into general transaction categories. For example, a transaction might be displayed as `/user/*/control_panel`, where the `*` represents different user names. To rename transactions or adjust how names are consolidated, use [custom instrumentation](https://docs.newrelic.com/docs/apm/agents/manage-apm-agents/agent-data/custom-instrumentation/). ## Monitoring transactions [#other-features] Here are some other ways you can use APM to monitor transactions: | If you want to monitor... | Use this... | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Transactions important to your business | Create [key transactions](https://docs.newrelic.com/docs/apm/transactions/key-transactions/introduction-key-transactions), which emphasizes them in the UI and lets you set a custom level of monitoring for them. | | Async activity | Follow the procedures to set up asynchronous activity for your specific [APM language agent](https://docs.newrelic.com/docs/apm/new-relic-apm/getting-started/introduction-apm). | | Activity across applications | Linking transactions across applications gives you more detail about business-relevant application activity. For more information, see the documentation about [distributed tracing](https://docs.newrelic.com/docs/apm/distributed-tracing/getting-started/introduction-distributed-tracing) and [cross application traces](https://docs.newrelic.com/docs/apm/transactions/cross-application-traces/introduction-cross-application-traces). > #### 💡 TIP > > To get a high-level overview of all your applications and services, use our [entity explorer](https://docs.newrelic.com/docs/new-relic-one/use-new-relic-one/ui-data/new-relic-one-entity-explorer). | ## Query transactions [#insights] Transactions are available for querying with an in-depth set of [default attributes](https://docs.newrelic.com/docs/insights/insights-data-sources/default-events-attributes/apm-default-event-attributes#transaction-event) attached. Using these attributes, you can run queries and create custom charts that APM does not provide by default. For information on how to query your data using our UI or NRQL, see [Query New Relic data](https://docs.newrelic.com/docs/using-new-relic/data/understand-data/query-new-relic-data).