Skip to content

Conversation

@rtrieu
Copy link
Contributor

@rtrieu rtrieu commented Nov 25, 2025

What does this PR do? What is the motivation?

Updates images and text for the RUM alerting guide to focus more metrics-based instead of events-based alerting.

Merge instructions

Merge readiness:

  • Ready for merge

For Datadog employees:

Your branch name MUST follow the <name>/<description> convention and include the forward slash (/). Without this format, your pull request will not pass CI, the GitLab pipeline will not run, and you won't get a branch preview. Getting a branch preview makes it easier for us to check any issues with your PR, such as broken links.

If your branch doesn't follow this format, rename it or create a new branch and PR.

[6/5/2025] Merge queue has been disabled on the documentation repo. If you have write access to the repo, the PR has been reviewed by a Documentation team member, and all of the required checks have passed, you can use the Squash and Merge button to merge the PR. If you don't have write access, or you need help, reach out in the #documentation channel in Slack.

Additional notes

@rtrieu rtrieu requested review from a team as code owners November 25, 2025 21:39
@github-actions github-actions bot added Images Images are added/removed with this PR Guide Content impacting a guide labels Nov 25, 2025
@github-actions
Copy link
Contributor

Preview links (active after the build_preview check completes)

Modified Files

@maycmlee
Copy link
Contributor

Created a docs card: https://datadoghq.atlassian.net/browse/DOCS-12782

@maycmlee maycmlee added the editorial review Waiting on a more in-depth review label Nov 25, 2025
- **Build a custom monitor**: Choose from out-of-the-box metrics or custom metrics, then scope to your application, specific pages, or views.

The example above is a search query for a RUM monitor configured for views on the Shopist iOS application with facets such as `Application ID` and `View Path`. This example monitor alerts when a view has a high amount of errors (for example, more than 8).
Learn more about [creating RUM Monitors][4].
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also update /monitors/types/real_user_monitoring? It's outdated too

Comment on lines 68 to 74
### Error rates

The ratio of errors to requests allows you to calculate what percentage of requests are resulting in errors.
The ratio of errors to requests shows what percentage of requests result in errors.

This example shows a RUM monitor for the error rate of the `/cart` page on a sample Shop.ist application.

{{< img src="real_user_monitoring/guide/alerting-with-rum/error-rate-example-monitor.png" alt="RUM monitor for error rates" style="width:100%;" >}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an event-based example, while we have out-of-the-box metrics for RUM without Limits customers for this. I would delete this section all together

Comment on lines +78 to +80
Real User Monitoring measures, calculates, and scores application performance as [Core Web Vitals][10] and [Mobile Vitals][11]. For example, Largest Contentful Paint (LCP) measures loading performance. A widely used benchmark is 2.5 seconds when the page starts loading.

This example shows a RUM monitor for the LCP of the `/cart` page on a sample Shop.ist application.
This example shows a RUM monitor for the LCP metric filtered to a specific application (for example, `Shop.ist`) and grouped by `view name` to track performance across different pages. Grouping by view name helps pinpoint which pages have performance issues.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The screenshot shows the INP metric, not the LCP. I don't mind advertising one or the other, but I just believe we should remain consistent

Co-authored-by: Maël Lilensten <mael.lilensten@datadoghq.com>
{{< img src="real_user_monitoring/guide/alerting-with-rum/export-to-monitor-3.mp4" alt="Export button to the right hand corner of the RUM Explorer" video="true" style="width:100%;" >}}
- **Visibility into your full traffic**: Metrics are computed over your full, unsampled traffic before retention filters apply to provide broader visibility into application health
- **Reduce the risk of missing issues**: Event-based monitors depend on retention filters and can miss issues if relevant events aren't indexed
- **Advanced capabilities**: Metric-based monitors support anomaly detection, outlier detection, and forecasts
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I missed this one

Suggested change
- **Advanced capabilities**: Metric-based monitors support anomaly detection, outlier detection, and forecasts
- **Advanced capabilities**: Metric-based monitors support anomaly detection

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rtrieu as I mentioned the text calls the LCP out while the screenshot shows the INP metric. Could you update the screenshot to show an LCP-based monitor and remain consistent with the rest of the paragraph please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

editorial review Waiting on a more in-depth review Guide Content impacting a guide Images Images are added/removed with this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants