# 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](viewing_metrics_with_cloudwatch.md).
You can also optionally send extended metrics to CloudWatch. For more information, see [Extended metrics](CloudWatch-RUM-custom-and-extended-metrics.md#CloudWatch-RUM-vended-metrics).
These metrics are published in the metric namespace named `AWS/RUM`. All of the following metrics are published with an `application_name` dimension. The value of this dimension is the name of the app monitor. Some metrics are also published with additional dimensions, as listed in the following table.
**Web metrics**
| Metric | Unit | Description |
| --- | --- | --- |
| `HttpStatusCodeCount` | Count | The count of HTTP responses in the application, by their response status code. Additional dimensions: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-metrics.html) |
| `Http4xxCount` | Count | The count of HTTP responses in the application, with 4xx response status code. These are calculated based on `http_event` RUM events that result in 4xx codes. |
| `Http4xxCountPerSession` | Count | The count of HTTP responses in a session, with 4xx response status code. These are calculated based on `http_event` RUM events that result in 4xx codes. |
| `Http4xxCountPerPageView` | Count | The count of HTTP responses in a page review, with 4xx response status code. These are calculated based on `http_event` RUM events that result in 4xx codes. |
| `Http5xxCount` | Count | The count of HTTP responses in the application, with 5xx response status code. These are calculated based on `http_event` RUM events that result in 5xx codes. |
| `Http5xxCountPerSession` | Count | The count of HTTP responses in the session, with 5xx response status code. These are calculated based on `http_event` RUM events that result in 5xx codes. |
| `Http5xxCountPerPageView` | Count | The count of HTTP responses in a page review, with 5xx response status code. These are calculated based on `http_event` RUM events that result in 5xx codes. |
| `JsErrorCount` | Count | The count of JavaScript error events ingested. |
| `JsErrorCountPerSession` | Count | The count of JavaScript error events ingested in a session. |
| `JsErrorCountPerPageView` | Count | The count of JavaScript error events ingested in a page review. |
| `NavigationFrustratedTransaction` | Count | The count of navigation events with a `duration` higher than the frustrating threshold, which is 8000ms. The duration of navigation events is tracked in the `PerformanceNavigationDuration` metric. |
| `NavigationSatisfiedTransaction` | Count | The count of navigation events with a `duration` that is less than the Apdex objective, which is 2000ms. The duration of navigation events is tracked in the `PerformanceNavigationDuration` metric. |
| `NavigationToleratedTransaction` | Count | The count of navigation events with a `duration` between 2000ms and 8000ms. The duration of navigation events is tracked in the `PerformanceNavigationDuration` metric. |
| `PageViewCount` | Count | The count of page view events ingested by the app monitor. This is calculated by counting the `page_view_event` RUM events. |
| `PageViewCountPerSession` | Count | The count of page view events in a session. |
| `PerformanceResourceDuration` | Milliseconds | The `duration` of a resource event. Additional dimensions: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-metrics.html) |
| `PerformanceNavigationDuration` | Milliseconds | The `duration` of a navigation event. |
| `RumEventPayloadSize` | Bytes | The size of every event ingested by CloudWatch RUM. You can also use the `SampleCount` statistic for this metric to monitor the number of events that an app monitor is ingesting. |
| `SessionCount` | Count | The count of session start events ingested by the app monitor. In other words, the number of new sessions started. |
| `SessionDuration` | Milliseconds | The duration of a session. These are calculated based on the time between first and last events in a session. |
| `TimeOnPage` | 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. |
| `WebVitalsCumulativeLayoutShift` | None | Tracks the value of the cumulative layout shift events. |
| `WebVitalsFirstInputDelay` | Milliseconds | Tracks the value of the first input delay events. |
| `WebVitalsLargestContentfulPaint` | Milliseconds | Tracks the value of the largest contentful paint events. |
| `WebVitalsInteractionToNextPaint` | 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.
**Mobile metrics**
| Metric | Unit | Description |
| --- | --- | --- |
| `ANRCount` | 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. |
| `AppHangCount` | Count | For iOS only: The number of times the application became unresponsive for more than 250ms on the main loop. |
| `ColdAppLaunchFrustratedTransaction` | Count | The number of cold app launches that took longer than 8 seconds to complete, likely causing user frustration. |
| `ColdAppLaunchSatisfiedTransaction` | Count | The number of cold app launches that completed in less than 2 seconds, providing a satisfactory user experience. |
| `ColdAppLaunchToleratedTransaction` | Count | The number of cold app launches that completed between 2 and 8 seconds, providing a tolerable, but not ideal, user experience. |
| `ColdLaunchTime` | Milliseconds | Time taken to launch the application from a terminated state. For Android: Time from Application `onCreate` until the first Activity finishes creating. For iOS: Time from application start (determined by `sysctl` process start command) until `didBecomeActiveNotification`. |
| `CrashCount` | 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. |
| `DroppedEventsCount` | Count | The number of log events that were dropped because they exceeded the maximum size limit of 30KB per event. |
| `DroppedSpansCount` | Count | The number of spans that were dropped because they exceeded the maximum size limit of 30KB per span. |
| `Http4xxCount` | Count | Records the number of HTTP client errors encountered by the web or mobile application during HTTP requests. |
| `Http5xxCount` | Count | Records the number of HTTP server errors encountered by the web or mobile application during HTTP requests. |
| `LogPayloadSize` | Bytes | The size in bytes of the log telemetry data being sent to CloudWatch RUM. You can also use the `SampleCount` statistic for this metric to monitor the number of Log Events that an app monitor is ingesting. |
| `NetworkLatency` | Milliseconds | The time taken for network requests to complete, measuring the round-trip time from request initiation to response completion. |
| `ScreenLoadCount` | Count | The total number of screen loads. |
| `ScreenLoadToleratedTransaction` | Count | The number of screen loads that completed between 2 and 8 seconds, providing a tolerable, but not ideal, user experience. |
| `SessionCount` | 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. |
| `SpanPayloadSize` | Bytes | The size in bytes of the span telemetry data being sent to CloudWatch RUM. You can also use the `SampleCount` statistic for this metric to monitor the number of Spans that an app monitor is ingesting. |
| `WarmAppLaunchFrustratedTransaction` | Count | The number of warm app launches that took longer than 8 seconds to complete, likely causing user frustration. |
| `WarmAppLaunchSatisfiedTransaction` | Count | The number of warm app launches that completed in less than 2 seconds, providing a satisfactory user experience. |
| `WarmAppLaunchToleratedTransaction` | Count | The number of warm app launches that completed between 2 and 8 seconds, providing a tolerable, but not ideal, user experience. |
| `WarmLaunchTime` | Milliseconds | Time taken to launch the application from background state. For Android: Time from Application `onCreate` until the first Activity finishes creating. For iOS: Time from `UIApplicationWillEnterForegroundNotification` until `didBecomeActiveNotification`. |
# Custom metrics and extended metrics that you can send to CloudWatch
By default, RUM app monitors send metrics to CloudWatch. These default metrics and dimensions are listed in [CloudWatch metrics that you can collect with CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-metrics.html).
You can also set up an app monitor to export metric. The app monitor can send extended metrics, custom metrics, or both. It can send them to CloudWatch.
+ **Custom metrics**— Custom metrics are metrics that you define. With custom metrics, you can use any metric name and namespace. To derive the metrics, you can use any custom events, built-in events, custom attributes, or default attributes.
You can send custom metrics to CloudWatch.
+ **Extended metrics**— You can send any of the default CloudWatch RUM metrics to CloudWatch with additional dimensions. This way, these metrics can give you a more fine-grained view.
**Topics**
+ [Custom metrics](#CloudWatch-RUM-custom-metrics)
+ [Extended metrics](#CloudWatch-RUM-vended-metrics)
## Custom metrics
To send custom metrics, you must use the AWS APIs or AWS CLI instead of the console. For more information about using the AWS APIs, see [PutRumMetricsDestination](https://docs.aws.amazon.com/cloudwatchrum/latest/APIReference/API_PutRumMetricsDestination.html) and [BatchCreateRumMetricDefinitions](https://docs.aws.amazon.com/cloudwatchrum/latest/APIReference/API_BatchCreateRumMetricDefinitions.html).
The maximum number of extended metric and custom metric definitions that one destination can contain is 2000. For each custom metric or extended metric that you send to each destination, each combination of dimension name and dimension value counts toward this limit. You are not charged for custom metrics derived from any kind of events or attributes of CloudWatch RUM.
The following example shows how to create a custom metric derived from a custom event. Here is the example custom event that is used:
```
cwr('recordEvent', {
type: 'my_custom_event',
data: {
location: 'IAD',
current_url: 'amazonaws.com',
user_interaction: {
interaction_1 : "click",
interaction_2 : "scroll"
},
visit_count:10
}
})
```
Given this custom event, you can create a custom metric that counts the number of visits to the `amazonaws.com` URL from Chrome browsers. The following definition creates a metric named `AmazonVisitsCount` in your account, in the `RUM/CustomMetrics/PageVisits` namespace.
```
{
"AppMonitorName":"customer-appMonitor-name",
"Destination":"CloudWatch",
"MetricDefinitions":[
{
"Name":"AmazonVisitsCount",
"Namespace":"PageVisit",
"ValueKey":"event_details.visit_count",
"UnitLabel":"Count",
"DimensionKeys":{
"event_details.current_url": "URL"
},
"EventPattern":"{\"metadata\":{\"browserName\":[\"Chrome\"]},\"event_type\":[\"my_custom_event\"],\"event_details\": {\"current_url\": [\"amazonaws.com\"]}}"
}
]
}
```
## Extended metrics
If you set up extended metrics, you can send any of the default CloudWatch RUM metrics to CloudWatch with additional dimensions so that the metrics give you a more fine-grained view.
For more information about the default CloudWatch RUM metrics, see [CloudWatch metrics that you can collect with CloudWatch RUM](CloudWatch-RUM-metrics.md).
The maximum number of extended metric and custom metric definitions that one destination can contain is 2000. For each extended or custom metric that you send to each destination, each combination of dimension name and dimension value counts as an extended metric for this limit.
When you send extended metrics to CloudWatch, you can use the CloudWatch RUM console to create CloudWatch alarms on them.
You are not charged for extended metrics that are created for the default metrics of CloudWatch RUM.
### Web Application Extended Metrics
The following dimensions are supported for web application extended metrics:
+ `BrowserName`
Example dimension values: `Chrome`, `Firefox`, `Chrome Headless`
+ `CountryCode` This uses the ISO-3166 format, with two-letter codes.
Example dimension values: `US`, `JP`, `DE`
+ `DeviceType`
Example dimension values: `desktop`, `mobile`, `tablet`, `embedded`
+ `FileType`
Example dimension values: `Image`, `Stylesheet`
+ `OSName`
Example dimension values: `Linux`, `Windows`, `iOS`, `Android`
+ `PageId`
### Mobile Application Extended Metrics
The following dimensions are supported for mobile application extended metrics:
+ `ScreenName`
+ Value from the screen name attribute - `attributes.screen.name` of your application
+ Example values: HomeScreen, SettingsView, ProfilePage
+ `DeviceModel`
+ Value from the device model attribute - `resource.attributes.device.model.name`
+ Example values: iPhone14,3, SM-G998B
+ `OSVersion`
+ Value from the operating system version attribute - `resource.attributes.os.version`
+ Example values: 16.0, 13.0
**Note**
Currently supported default metrics for mobile applications: `ScreenLoadTime`, `ScreenLoadCount`, `NetworkLatency`, `Http4xxCount`, `Http5xxCount`, `CrashCount`, `ANRCount`, `AppHangCount`, `ColdLaunchTime`, `WarmLaunchTime`, `SessionCount`, `SpanPayloadSize` and `LogPayloadSize`.
### Set up extended metrics using the console
To use the console to send extended metrics to CloudWatch, use the following steps.
For information about using the AWS APIs to send extended metrics to either CloudWatch, see [PutRumMetricsDestination](https://docs.aws.amazon.com/cloudwatchrum/latest/APIReference/API_PutRumMetricsDestination.html) and [BatchCreateRumMetricDefinitions](https://docs.aws.amazon.com/cloudwatchrum/latest/APIReference/API_BatchCreateRumMetricDefinitions.html).
**To use the console to set up an app monitor and send RUM extended metrics to CloudWatch**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, choose **Application Signals**, **RUM**.
1. Choose the name of the app monitor that is to send the metrics.
1. Choose the **Configuration** tab and then choose **RUM extended metrics**.
1. Choose **Send metrics**.
1. Select one or more metric names to send with additional dimensions.
1. Select one or more factors to use as dimensions for these metrics. As you make your choices, the number of extended metrics that your choices create is displayed in **Number of extended metrics**.
This number is calculated by multiplying the number of chosen metric names by the number of different dimensions that you create.
1. To send a metric with page ID as a dimension, choose **Browse for page ID** and then select the page IDs to use.
1. To send a metric with device type as a dimension, choose either **Desktop devices** or **Mobile and tablets**.
1. To send a metric with operating system as a dimension, select one or more operating systems under **Operating system**.
1. To send a metric with browser type as a dimension, select one or more browsers under **Browsers**.
1. To send a metric with geolocation as a dimension, select one or more locations under **Locations**.
Only the locations where this app monitor has reported metrics from will appear in the list to choose from.
1. When you are finished with your choices, choose **Send metrics**.
1. (Optional) In the **Extended metrics** list, to create an alarm that watches one of the metrics, choose **Create alarm** in that metric's row.
For general information about CloudWatch alarms, see [Using Amazon CloudWatch alarms](CloudWatch_Alarms.md). For a tutorial for setting an alarm on a CloudWatch RUM extended metric, see [Tutorial: create an extended metric and alarm it](#CloudWatch-RUM-extended-metrics-alarmtutorial).
**Stop sending extended metrics**
**To use the console to stop sending extended metrics**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, choose **Application Signals**, **RUM**.
1. Choose the name of the app monitor that is to send the metrics.
1. Choose the **Configuration** tab and then choose **RUM extended metrics**.
1. Select one or more metric name and dimension combinations to stop sending. Then choose **Actions**, **Delete**.
### Tutorial: create an extended metric and alarm it
This tutorial demonstrates how to set up an extended metric to be sent to CloudWatch, and then how to set an alarm on that metric. In this tutorial, you create a metric that tracks JavaScript errors on the Chrome browser.
**To set up this extended metric and set an alarm on it**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, choose **Application Signals**, **RUM**.
1. Choose the name of the app monitor that is to send the metric.
1. Choose the **Configuration** tab and then choose **RUM extended metrics**.
1. Choose **Send metrics**.
1. Select **JSErrorCount**.
1. Under **Browsers**, select **Chrome**.
This combination of **JSErrorCount** and **Chrome** will send one extended metric to CloudWatch. The metric counts JavaScript errors only for user sessions that use the Chrome browser. The metric name will be **JsErrorCount** and the dimension name will be **Browser**.
1. Choose **Send metrics**.
1. In the **Extended metrics** list, choose **Create alarm** in the row that displays **JsErrorCount** under **Name** and displays **Chrome** under **BrowserName**.
1. Under **Specify metric and conditions**, confirm that the **Metric name** and **BrowserName** fields are pre-filled with the correct values.
1. For **Statistic**, select the statistic that you want to use for the alarm. **Average** is a good choice for this type of counting metric.
1. For **Period**, select **5 minutes**.
1. Under **Conditions**, do the following:
+ Choose **Static**.
+ Choose **Greater** to specify that the alarm should go into ALARM state when the number of errors is higher than the threshold you are about to specify.
+ Under **than...**, enter the number for the alarm threshold. The alarm goes into ALARM state when the number of errors over a 5-minute period exceeds this number.
1. (Optional) By default, the alarm goes into ALARM state as soon as the number of errors exceeds the threshold number you set during a 5-minute period. You can optionally change this so that the alarm goes into ALARM state only if this number is exceeded for more than one 5-minute period.
To do so, choose **Additional configuration** and then for **Datapoints to alarm**, specify how many 5-minute periods need to have the error number over the threshold to trigger the alarm. For example, you can select 2 out of 2 to have the alarm trigger only when two consecutive 5-minute periods are over the threshold, or 2 out of 3 to have the alarm trigger if any two of three consecutive 5-minute periods are over the threshold.
For more information about this type of alarm evaluation, see [Alarm evaluation](alarm-evaluation.md).
1. Choose **Next**.
1. For **Configure actions**, specify what should happen when the alarm goes into alarm state. To receive a notification with Amazon SNS, do the following:
+ Choose **Add notification**.
+ Choose **In alarm**.
+ Either select an existing SNS topic or create a new one. If you create a new one, specify a name for it and add at least one email address to it.
1. Choose **Next**.
1. Enter a name and optional description for the alarm, and choose **Next**.
1. Review the details and choose **Create alarm**.