RUM Event Attributes

Table of Contents

Every RUM event type carries its own set of attributes on top of the shared session, device, browser, and geo context described in RUM Explorer. This page is the attribute reference for the four child event types — Views, Actions, Resources, and Errors — that make up a user session; browse them live from RUM > Explorer by setting Event Type — see Event Types.

Views

View events represent navigation to different parts of your frontend application. This includes page loads and transitions within a single page application.

A view event holds attributes such as the Page URL and also includes rich statistics including Web Vitals such as First Contentful Paint (FCP), Largest Contentful Paint (LCP), Interaction to Next Paint (INP) as well as timing statistics such as DOM Interactive and DOM Content Loaded.

All user interactions (Action events), resource loads (Resource events), and other RUM event such as Error and Long Task events occur in the context of an active view and view events maintain aggregate statistics across these child events.

Opening a view event shows its full attributes, Web Vitals, and child Action/Resource/Error/Long Task counts in the event detail panel, and its Performance tab breaks down the same timing data shown in aggregate on RUM Performance.

Actions

An action corresponds to a user activity such as a click, a tap, a scroll etc. From the observability perspective, an action has quite a few important properties that can provide insights into users' behavior patterns. They also inherit properties from the active parent view.

Action.id

Unique identifier for every action.

Usage

Distinguish actions, even ones with the same name

Example

f58b24dd-d781-47be-ad6c-0f89af469e46'

Action.name

Concatenation of the user activity and the UI element (target) it was performed on. Many distinct actions may have the same name eg a user clicking the same button twice or two different users clicking on the same button in separate sessions.

Usage

Group actions by name to see the count of the most frequently performed action.

Example

Click Trace Analytics

Action.loading_time

The loading time of the action. It is calculated from the time the user interacts with a UI target to the time that the page has no more activity.

Usage

Filter actions that have loading times in a certain time range, or perform percentile analytics to profile the slowest or critical ones.

Example

165 ms

Action.long_task.count

Any browser task that blocks the main thread for more than 50ms is a long_task.

Usage

Filter actions that have long_task.count in a certain range.

Example

2

Action.resource.count

A resource event is triggered for a resource fetch such as images, XHR, Fetch, CSS, or JS libraries loaded on a webpage.

Usage

Get the median (percentile 50) count of resource fetches per action.

Example

10

Action.error_count

UI error emitted by the browser.

Usage

Get the actions with the most errors to isolate workflows and steps that lead to frequent errors.

Example

0

Resources

A resource event corresponds to a resource or asset fetch on a webpage such as an image, XHR, Fetch, CSS, or JS library. A resource is a child event to an action event. It also has the context of the view that is currently active. If RUM and APM are linked, a resource whose backend request was traced carries a link to that trace.

The following properties may be used to analyze and profile resources in a session:

duration

Overall time spent fetching the resource

Usage

Analytics can be performed to get the slowest loading resources

Example

48ms

resource.size

Resource size

Usage

Analytics can be performed to see the size distribution of the resources

Example

912B

resource.connect.duration

Time to establish connection to resource server

Usage

Insight into users' reachability of resource

Example

20ms

resource.ssl.duration

TLS handshake time for HTTPS connections

Usage

Diagnose whether problem lies with the user’s network

Example

15ns

resource.dns.duration

DNS resolution time

Usage

Diagnose whether problem lies with the user’s network

Example

23ms

resource.redirect.duration

Time spent on downstream HTTPS requests

Usage

Redirect analytics or filtering

Example

30ms

resource.first_byte.duration

Waiting time to receive the first byte of the resource

Usage

Can be used to find out the rate determining resource in a view

Example

30ms

resource.download.duration

Response download time

Usage

Analytics can be performed to determine if the storage solution for the resource is slow.

Example

24ms

resource.type

Type of resource being fetched.

Usage

Filter analytics based on resource type

Example

javascript, css

resource.method

HTTP method

Usage
Example

POST

resource.status_code

Response code

Usage
Example

202

resource.url

URL of the resource being fetched

Usage
Example
resource.url_host

URL host

Usage
Example
resource.url_path

URL path

Usage
Example
resource.url_query

URL query parameters

Usage
Example
resource.url_scheme

Protocol type

Usage
Example

HTTP, HTTPS

resource.provider.name

Resource provider name

Usage
Example
resource.provider.domain

Resource domain

Usage
Example
resource.provider.type

The type of content provider

Usage
Example

cdn, first-party

Errors

RUM Errors captures frontend errors that occur in your application, including both unhandled exceptions and errors explicitly reported by your code. Each error event records the error message and stack trace when available, and Kloudfuse automatically groups similar errors together for easier analysis and troubleshooting.

The Errors event type in the Explorer has an Error Groups sub-tab that clusters similar errors by their message and stack trace, showing the error Type, originating Service, Occurrences, and First seen/Last seen timestamps for each group — the same summary that the Performance screen’s Errors tab surfaces as Ongoing issues.

Open any error event or error group to see its full message and stack trace in the event detail panel. If RUM and APM are linked, errors that occurred during a traced backend call also carry a link to that trace.