CloudWatch metrics that you can collect with CloudWatch RUM
The tables in this section lists the metrics that you automatically collect with CloudWatch RUM from web applications, mobile applications, or both. You can see these metrics in the CloudWatch console. For more information, see View available metrics.
You can also optionally send extended metrics to CloudWatch. For more information, see Extended metrics.
These metrics are published in the metric namespace named AWS/RUM.
CloudWatch RUM publishes the web and mobile metrics in the following tables with an
application_name dimension. The value of this dimension is the name
of the app monitor. CloudWatch RUM also publishes some metrics with additional dimensions,
as listed in the following tables.
The following table describes the web metrics.
| Metric | Unit | Description |
|---|---|---|
|
|
Count |
The count of HTTP responses in the application, by their response status code. Additional dimensions:
|
|
|
Count |
The count of HTTP responses in the application, with 4xx response status code. These are calculated based on |
|
|
Count |
The count of HTTP responses in a session, with 4xx response status code. These are calculated based on |
|
|
Count |
The count of HTTP responses in a page review, with 4xx response status code. These are calculated based on |
|
|
Count |
The count of HTTP responses in the application, with 5xx response status code. These are calculated based on |
|
|
Count |
The count of HTTP responses in the session, with 5xx response status code. These are calculated based on |
|
|
Count |
The count of HTTP responses in a page review, with 5xx response status code. These are calculated based on |
|
|
Count |
The count of JavaScript error events ingested. |
|
|
Count |
The count of JavaScript error events ingested in a session. |
|
|
Count |
The count of JavaScript error events ingested in a page review. |
|
|
Count |
The count of navigation events with a |
|
|
Count |
The count of navigation events with a |
|
|
Count |
The count of navigation events with a |
|
|
Count |
The count of page view events ingested by the app monitor. This is calculated by counting the |
|
|
Count |
The count of page view events in a session. |
|
|
Milliseconds |
The Additional dimensions:
|
|
|
Milliseconds |
The |
|
|
Bytes |
The size of every event ingested by CloudWatch RUM. You can also use the
|
|
|
Count |
The count of session start events ingested by the app monitor. In other words, the number of new sessions started. |
|
|
Milliseconds |
The duration of a session. These are calculated based on the time between first and last events in a session. |
|
|
Milliseconds |
The duration of a page view. These are calculated based on the time until next page view, except for the final page in a session where it's the time between first and last events on that page. |
|
|
None |
Tracks the value of the cumulative layout shift events. |
|
|
Milliseconds |
Tracks the value of the first input delay events. |
|
|
Milliseconds |
Tracks the value of the largest contentful paint events. |
|
|
Milliseconds |
Tracks the value of the interaction to next paint events. |
You can configure extended metrics for your mobile application to provide additional dimensions for analysis.
| Metric | Unit | Description |
|---|---|---|
|
|
Count |
For Android only: The number of Application Not Responding (ANR) incidents, occurring when the application is unresponsive for more than 5 seconds, resulting in application crash. |
|
|
Count |
For iOS only: The number of times the application became unresponsive for more than 250ms on the main loop. |
|
|
Count |
The number of cold app launches that took longer than 8 seconds to complete, likely causing user frustration. |
|
|
Count |
The number of cold app launches that completed in less than 2 seconds, providing a satisfactory user experience. |
|
|
Count |
The number of cold app launches that completed between 2 and 8 seconds, providing a tolerable, but not ideal, user experience. |
|
|
Milliseconds |
Time taken to launch the application from a terminated state. For Android: Time from Application For iOS: Time from application start (determined by
|
|
|
Count |
The number of unexpected application terminations caused by unhandled exceptions or OS termination. For Android: Crashes due to unhandled exceptions or system termination. For iOS: Crashes due to unhandled exceptions, fatal errors, or system termination. Crash data is stored locally and reported on next app launch. |
|
|
Count |
The number of log events that were dropped because they exceeded the maximum size limit of 30KB per event. |
|
|
Count |
The number of spans that were dropped because they exceeded the maximum size limit of 30KB per span. |
|
|
Count |
Records the number of HTTP client errors encountered by the web or mobile application during HTTP requests. |
|
|
Count |
Records the number of HTTP server errors encountered by the web or mobile application during HTTP requests. |
|
|
Bytes |
The size in bytes of the log telemetry data being sent to CloudWatch RUM. You can also use the |
|
|
Milliseconds |
The time taken for network requests to complete, measuring the round-trip time from request initiation to response completion. |
|
|
Count |
The total number of screen loads. |
|
|
Count |
The number of screen loads that completed between 2 and 8 seconds, providing a tolerable, but not ideal, user experience. |
|
|
Count |
The total number of unique user sessions with the application. A session begins when the user opens the app and ends after 30 minutes of inactivity or when explicitly terminated. |
|
|
Bytes |
The size in bytes of the span telemetry data being sent to CloudWatch RUM. You can also use the |
|
|
Count |
The number of warm app launches that took longer than 8 seconds to complete, likely causing user frustration. |
|
|
Count |
The number of warm app launches that completed in less than 2 seconds, providing a satisfactory user experience. |
|
|
Count |
The number of warm app launches that completed between 2 and 8 seconds, providing a tolerable, but not ideal, user experience. |
|
|
Milliseconds |
Time taken to launch the application from background state. For Android: Time from Application For iOS: Time from
|
CloudWatch RUM also publishes request and throttling metrics in the AWS/RUM namespace in all Regions where CloudWatch RUM is available. These metrics are account-level metrics. CloudWatch RUM publishes them to the AWS account that calls the API. They don't have the application_name dimension. Instead, they have an Operation dimension with one of the following values:
-
PutRumEvents– Requests from web applications -
PutRumOtelEvents– Requests from mobile applications that use OpenTelemetry
The following table describes the request and throttling metrics.
| Metric | Unit | Description |
|---|---|---|
|
|
None |
The number of requests that CloudWatch RUM received for the operation. CloudWatch RUM counts requests before applying throttling, so this metric includes throttled requests. To monitor requests per second, use the |
|
|
None |
The number of requests for the operation that CloudWatch RUM throttled because they exceeded the request rate quota for your account. CloudWatch RUM rejects these requests with a |
The most useful statistic for these metrics is Sum. To know when you might need a quota increase, create an alarm that goes into ALARM state when ThrottledRequestCount is greater than 0. For information about CloudWatch RUM quotas and how to request an increase, see CloudWatch RUM quotas.