---
title: Operations Monitoring
description: >-
  Monitor critical technical operations within user-facing journeys to identify
  exactly when and why users fail to complete key workflows.
breadcrumbs: Docs > RUM & Session Replay > Operations Monitoring
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Operations Monitoring

## Overview{% #overview %}

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-overview-2.15f952103207800b34053087d2d6714f.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-overview-2.15f952103207800b34053087d2d6714f.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Operations tab under RUM > Performance Monitoring." /%}

A RUM operation is a critical step in a [journey](https://docs.datadoghq.com/journey_monitoring.md) that must be available and fast for users to complete the journey. A journey represents a major user-facing area of your application, such as checkout, login, or search. You define RUM operations for the steps that matter in your application. An operation typically starts with a user action and ends when a related technical event completes, such as when an API call resolves.

Datadog automatically generates operation metrics from all ingested, unsampled RUM traffic at no additional cost. Use operation events in [retention filters](https://docs.datadoghq.com/real_user_monitoring/rum_without_limits/retention_filters.md) or investigate them in retained RUM sessions.

You can create operations in the following ways:

- With the RUM SDK APIs
- Directly in Datadog
- Through the Datadog MCP (Model Context Protocol) Server
- Programmatically with the Datadog API

For recommendations on defining and instrumenting operations, see [Best Practices for Setting Up RUM Operations](https://docs.datadoghq.com/real_user_monitoring/guide/best-practices-for-operations-setup.md).

Grouping RUM operations into journeys connects technical performance with business outcomes:

- Engineering teams use **operations** to monitor and minimize technical failures that affect key moments in a journey.
- Business teams use **journeys** to track and improve user conversion.

For example, the checkout experience of an ecommerce platform is a journey. Its operations might include loading the checkout form, saving a payment method, and completing a purchase. Monitoring the health of these operations helps you identify when and why users do not complete the checkout journey.

The table lists additional example journeys and their associated operations by industry.

| Industry       | Journey  | Operations                                                                                                           |
| -------------- | -------- | -------------------------------------------------------------------------------------------------------------------- |
| Social network | Profile  | Users can load their profileUsers can upload a pictureUsers can update their status                                  |
| Ecommerce      | Checkout | Users can enter payment detailsUsers can save their payment methodUsers can pay                                      |
| Streaming      | Search   | Users can find results for their searchUsers can load the description of a titleUsers can start watching the trailer |
| CRM            | Quote    | Users can start a new quoteUsers can add line items to the quoteUsers can send a quote to recipients                 |

## Prerequisites{% #prerequisites %}

- [RUM without Limits](https://docs.datadoghq.com/real_user_monitoring/rum_without_limits.md) must be enabled in your organization.
- To create operations with SDK APIs, download a supported Datadog RUM SDK version with client-side APIs to define operations:
  - [Browser (6.20.0)](https://github.com/DataDog/browser-sdk/releases/tag/v6.20.0)
  - [Android (3.1.0)](https://github.com/DataDog/dd-sdk-android/releases/tag/3.1.0)
  - [iOS (3.1.0)](https://github.com/DataDog/dd-sdk-ios/releases/tag/3.1.0)
  - [Flutter (3.0.0)](https://github.com/DataDog/dd-sdk-flutter/releases/tag/datadog_flutter_plugin%2Fv3.0.0)
    - **Note**: On Flutter Web, operations route through the Browser SDK, which requires the `feature_operation_vital` experimental feature to be enabled.
  - [Kotlin Multiplatform (1.4.0)](https://github.com/DataDog/dd-sdk-kotlin-multiplatform/releases/tag/1.4.0)
  - [React Native (3.0.0)](https://github.com/DataDog/dd-sdk-reactnative/releases/tag/3.0.0)
  - [Roku (1.4.0)](https://github.com/DataDog/dd-sdk-roku/releases/tag/1.4.0)

## Monitor RUM operations with included metrics{% #monitor-rum-operations-with-included-metrics %}

Datadog automatically generates two out-of-the-box metrics for each RUM operation at no additional cost. The metrics use your full, ingested, unsampled traffic and are available to all [RUM without Limits](https://docs.datadoghq.com/real_user_monitoring/rum_without_limits.md) customers who define at least one operation:

- `rum.measure.operation` counts the volume of operations reported to Datadog.
- `rum.measure.operation.duration` measures the elapsed time between the start and end of operations reported to Datadog.

Datadog retains both metrics for 15 months. The metrics include these dimensions:

- `operation.name`, defined on the client side
- `operation.status`, either `success` or `failure`
- `operation.failure_reason`, either `error`, `abandoned`, or `other`

Use these metrics to create [metric monitors](https://docs.datadoghq.com/monitors/types/metric.md) and availability or latency Service Level Objectives (SLOs) for RUM operations. For recommended queries, thresholds, and examples, see [Best Practices for Creating SLOs for RUM Operations](https://docs.datadoghq.com/real_user_monitoring/guide/best-practices-for-creating-slos-on-operations.md).

To view operation metrics, navigate to RUM > Performance Monitoring > Operations. The Operations catalog groups together all operations with the same name.

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-catalog-2.45165b0daabd1fa989e0b90b30324005.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-catalog-2.45165b0daabd1fa989e0b90b30324005.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="RUM Operations catalog showing operation volume, completion rate, and failure rate." /%}

## Use RUM operation events for investigation and retention{% #use-rum-operation-events-for-investigation-and-retention %}

Each RUM operation generates a RUM event within its associated RUM session. An operation event can span multiple RUM views.

Query operation events from retained sessions in the [RUM Session Explorer](https://docs.datadoghq.com/real_user_monitoring/explorer.md) to investigate operation performance and failures. Along with standard RUM event attributes such as country, browser, and service, operation events include these operation-specific attributes:

- `@operation.name`
- `@operation.status`
- `@operation.failure_reason`
- `@operation.duration`
- `@operation.start_view.name`
- `@operation.end_view.name`

Use the same attributes in [retention filters](https://docs.datadoghq.com/real_user_monitoring/rum_without_limits/retention_filters.md) to retain sessions based on operation activity. For example, retain sessions that contain a failed operation or an operation whose duration exceeds a threshold.

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-retention-filter.14240928fd18f2314c3a8ab6a75a3c29.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-retention-filter.14240928fd18f2314c3a8ab6a75a3c29.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="RUM retention filter configured with operation event attributes." /%}

## Create operations with the SDK APIs{% #create-operations-with-the-sdk-apis %}

Use the SDK APIs to define your operations.

### Start an operation{% #start-an-operation %}

Every operation must be started by calling `startOperation` (some SDKs may use the legacy name of this API - `startFeatureOperation`).

{% tab title="Browser" %}

```javascript
DD_RUM.init({
...,
enableExperimentalFeatures: ["feature_operation_vital"], // you need to have this flag turned on for the API to work
})

startFeatureOperation: (
name: string,
options?: {
 operationKey?: string,
 context?: Context,
 description?: string,
}) => void
```

{% /tab %}

{% tab title="Android" %}

```kotlin
GlobalRumMonitor.get().startOperation(
	name: String,
	operationKey: String?,
	options: OperationOptions,
	attributes: Map<String, Any?>
)
```

{% /tab %}

{% tab title="iOS" %}

```swift
RUMMonitor.shared().startOperation(
	name: String,
	operationKey: String?,
	attributes: [AttributeKey: AttributeValue]?,
	options: OperationOptions?
)
```

{% /tab %}

{% tab title="React Native" %}

```javascript
DdRum.startFeatureOperation(
	name: string,
	operationKey?: string,
	attributes?: Record<string, any>
)
```

{% /tab %}

{% tab title="Flutter" %}

```dart
DatadogSdk.instance.rum?.startFeatureOperation(
    String name, {
    String? operationKey,
    Map<String, Object?> attributes = const {},
  }
)
```

To use operations on Flutter Web, enable the `feature_operation_vital` experimental feature in the Browser SDK.
{% /tab %}

{% tab title="Roku" %}

```
m.global.datadogRumAgent@.startOperation(
    name as string,
    operationKey = invalid as dynamic, ' optional: string or invalid for unkeyed operations
    context = {} as object             ' optional: AssocArray of custom attributes
)
```

{% /tab %}

{% alert level="warning" %}
The Operation's name may only contain letters, digits, or the characters `- _ . @ $`, and cannot contain any whitespaces.
{% /alert %}

### Stop an operation with success{% #stop-an-operation-with-success %}

Every started operation must have a stop. Use `succeedOperation` to stop an operation with a successful outcome (some SDKs may use the legacy name of this API - `succeedFeatureOperation`).

{% tab title="Browser" %}

```javascript
succeedFeatureOperation: (
name: string,
options?: {
 operationKey?: string,
 context?: Context,
 description?: string,
}) => void
```

{% /tab %}

{% tab title="Android" %}

```kotlin
GlobalRumMonitor.get().succeedOperation(
	name: String,
	operationKey: String?,
	attributes: Map<String, Any?>
)
```

{% /tab %}

{% tab title="iOS" %}

```swift
RUMMonitor.shared().succeedOperation(
	name: String,
	operationKey: String?,
	attributes: [AttributeKey: AttributeValue]?
)
```

{% /tab %}

{% tab title="React Native" %}

```javascript
DdRum.succeedFeatureOperation(
	name: string,
	operationKey?: string,
	attributes?: Record<string, any>
)
```

{% /tab %}

{% tab title="Flutter" %}

```dart
DatadogSdk.instance.rum?.succeedFeatureOperation(
    String name, {
    String? operationKey,
    Map<String, Object?> attributes = const {},
  }
)
```

To use operations on Flutter Web, enable the `feature_operation_vital` experimental feature in the Browser SDK.
{% /tab %}

{% tab title="Roku" %}

```
m.global.datadogRumAgent@.succeedOperation(
    name as string,
    operationKey = invalid as dynamic, ' optional: string or invalid for unkeyed operations
    context = {} as object             ' optional: AssocArray of custom attributes
)
```

{% /tab %}

{% alert level="warning" %}
The `operationKey` must be the same in the start and end Operation event.
{% /alert %}

### Stop an operation with failure{% #stop-an-operation-with-failure %}

Every started operation must have a stop. Use `failOperation` to stop an operation with a failure outcome (some SDKs may use the legacy name of this API - `failFeatureOperation`).

{% tab title="Browser" %}

```javascript
DD_RUM.init({
...,
enableExperimentalFeatures: ["feature_operation_vital"], // this flag needs to be enabled for the API to work
})

failFeatureOperation: (
name: string, 
failureReason: FailureReason, //'error' | 'abandoned' | 'other'
options?: {
 operationKey?: string,
 context?: Context,
 description?: string,
}) => void
```

{% /tab %}

{% tab title="Android" %}

```kotlin
GlobalRumMonitor.get().failOperation(
	name: String,
	operationKey: String?,
	failureReason: FailureReason,	// ERROR, ABANDONED, OTHER
	attributes: Map<String, Any?>
)
```

{% /tab %}

{% tab title="iOS" %}

```swift
RUMMonitor.shared().failOperation(
	name: String,
	operationKey: String?,
    reason: RUMFeatureOperationFailureReason,  // .error, .abandoned, .other
	attributes: [AttributeKey: AttributeValue]
)
```

{% /tab %}

{% tab title="Roku" %}

```
m.global.datadogRumAgent@.failOperation(
    name as string,
    failureReason as string,           ' "error", "abandoned", or "other"
    operationKey = invalid as dynamic, ' optional: string or invalid for unkeyed operations
    context = {} as object             ' optional: AssocArray of custom attributes
)
```

{% /tab %}

{% tab title="React Native" %}

```javascript
DdRum.failFeatureOperation(
	name: string,
	operationKey?: string,
	reason: FeatureOperationFailure, // 'ERROR' | 'ABANDONED' | 'OTHER'
	attributes: Record<string, any>
)
```

{% /tab %}

{% tab title="Flutter" %}

```dart
DatadogSdk.instance.rum?.failFeatureOperation(
    String name,
    RumFeatureOperationFailureReason failureReason, // .error, .abandoned, .other
    {
    String? operationKey,
    Map<String, Object?> attributes = const {},
  }
)
```

To use operations on Flutter Web, enable the `feature_operation_vital` experimental feature in the Browser SDK.
{% /tab %}

### Parallelization{% #parallelization %}

You may have cases where users are starting several journey operations in parallel. To individually track them, use the `operationKey` defined when calling `startOperation`. You must reuse the same `operationKey` later in other APIs, for example when calling `succeedOperation`.

{% alert level="warning" %}
Operations that have been started but not explicitly stopped are automatically terminated when the RUM session expires. Those are marked as failed, with `@operation.failure_reason:timeout`.  If an operation stop API was called that was not started in the first place, the stop event emitted by the SDK is dropped upon ingestion.
{% /alert %}

## Create operations from Datadog{% #create-operations-from-datadog %}

You can create an operation from either the operations catalog or a journey's details report:

- **Operations catalog**: Navigate to RUM > Operations, then click New Operation
- **Journey Monitoring**: Navigate to Digital Experience > Journey Monitoring, select a journey, navigate to its Details Report, then click New Operation

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-web-ui.13f641915a41d42aba0bcba562998139.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-web-ui.13f641915a41d42aba0bcba562998139.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Page for creating Operations from the Datadog UI" /%}

{% alert level="warning" %}
Each RUM application supports up to 1000 operations created from Datadog through the UI or API. There is no organization-wide limit on operations created directly in Datadog.
{% /alert %}

### Step 1: Enter operation details and select the operation category{% #step-1-enter-operation-details-and-select-the-operation-category %}

Select the operation's RUM application and enter a display name. You may optionally add a description to the operation.

Select the operation's **category** to determine the RUM event types compatible with the start, success, and failure conditions.

| Operation category        | Summary                                                                           | Supported event types                                                                                    |
| ------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Component loading         | Measure how long a user-initiated action takes to complete                        | Start: ActionSuccess: Resource or custom actionFailure: Resource, error, or custom action                |
| Form submission           | Measure how long a form submit or mutation takes to succeed                       | Start: ActionSuccess: Resource, view, or custom actionFailure: Resource, error, or custom action         |
| Page or screen load       | Measure how long a page or screen takes to load and display data                  | Start: ViewSuccess: Resource, view, or custom actionFailure: Resource, error, or custom action           |
| Page or screen navigation | Measure how long a navigation from one page or screen to another takes to succeed | Start: Action or viewSuccess: Resource, view, or custom actionFailure: Resource, error, or custom action |
| Custom                    | Define a custom operation with any event type combination                         | Start: Action or viewSuccess: Resource, view, or custom actionFailure: Resource, error, or custom action |

### Step 2: Define the start event{% #step-2-define-the-start-event %}

Each operation must have a starting RUM event. Operations can begin with either an action or view event depending on the selected operation category.

### Step 3: Define the success conditions{% #step-3-define-the-success-conditions %}

Each operation must have a condition for ending in a success. Operations can end in success with a resource, view, or custom action event, depending on the selected operation category.

### Step 4: Define the failure conditions{% #step-4-define-the-failure-conditions %}

Each operation must have a condition for ending in a failure:

- **Error** failures can end as a resource, error, or custom action.
- **Abandon** failures can be toggled on in case the user navigates away from the starting view before the operation finishes.

{% alert level="danger" %}
Allow up to 15 minutes for metrics to appear in the operations catalog after you create an operation in Datadog through the UI or API.
{% /alert %}

## Create operations with the Datadog MCP{% #create-operations-with-the-datadog-mcp %}

Operations can also be created through the [Datadog MCP](https://docs.datadoghq.com/mcp_server/tools.md#rum).

## Create operations with the Datadog API{% #create-operations-with-the-datadog-api %}

Operations can also be created through the [Datadog API](https://docs.datadoghq.com/api/latest/rum-operations.md).

## Edit operations{% #edit-operations %}

In the operations catalog, click the pencil icon to edit an operation. You can edit the description of any operation, regardless of how it was created. Operations created through the UI or API can be fully edited (not just the description).

## Link RUM operations to journeys{% #link-rum-operations-to-journeys %}

A link marks a RUM operation as part of the critical path of one or more journeys. Links distinguish operations that support a journey from unrelated operations that run at the same time.

Linking an operation to a journey has these effects:

- If the operation has no SLOs, Datadog creates an availability SLO with a 99% objective as a baseline. For guidance on customizing operation SLOs, see [Best Practices for Creating SLOs for RUM Operations](https://docs.datadoghq.com/real_user_monitoring/guide/best-practices-for-creating-slos-on-operations.md).
- The journey's [health status in Journey Monitoring](https://docs.datadoghq.com/journey_monitoring.md) reflects whether any SLO for the linked operation has a critical burn rate.

### Manage journey links{% #manage-journey-links %}

Manage links with one of these methods:

- In Datadog, from the operation's details report or a journey's [details report](https://docs.datadoghq.com/journey_monitoring/details_report.md)
- With the [RUM Operations API](https://docs.datadoghq.com/api/latest/rum-operations.md)

{% image
   source="https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-journey-link-side-panel.e01749293fa92ffeaaa37ee39f7ded50.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/real_user_monitoring/operations_monitoring/operations-monitoring-journey-link-side-panel.e01749293fa92ffeaaa37ee39f7ded50.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Side panel in RUM Operations details report to manage journey links." /%}

You can unlink an operation from a journey at any time. The operation keeps its SLOs after you unlink it.

## Investigate root causes with Bits AI{% #investigate-root-causes-with-bits-ai %}

When you open an operation, RUM displays recommendation cards ranked by severity, one for each type of problem affecting the operation: errors, abandonment, timeouts, crashes, or slowness. Click **Investigate** on a card to start a Bits Investigation that analyzes the problem down to the code. For more information, see [Optimize Performance with Bits AI](https://docs.datadoghq.com/real_user_monitoring/bits_ai/optimize_performance.md#operations-monitoring).

## Further Reading{% #further-reading %}

Additional helpful documentation, links, and articles:

- [Learn about RUM](https://docs.datadoghq.com/monitors/create/types/real_user_monitoring.md)
- [Best practices for setting up Operations Monitoring](https://docs.datadoghq.com/real_user_monitoring/guide/best-practices-for-operations-setup.md)
- [Best practices for creating SLOs for RUM operations](https://docs.datadoghq.com/real_user_monitoring/guide/best-practices-for-creating-slos-on-operations.md)