Try it free

Recreate measurements, analysis, and operations

  • Latest Dynatrace
  • How-to guide
  • 10-min read
  • Published Oct 06, 2026

In RUM Classic, monitoring workflows are built around per-application dashboards, USQL queries, metric events, and the USQL export API. RUM stores all data in Grail and surfaces it through DQL, Dashboards Dashboards, Notebooks Notebooks, built-in apps, and a unified alerting model. This page walks you through recreating relevant measurements, analysis, and operational workflows after you switch a frontend from RUM Classic to RUM.

Built-in metrics

What changed

RUM Classic exposes a set of built-in metrics scoped per application, pinnable to Dashboards via Data Explorer. These include various action counts, duration metrics, error rates, and Apdex scores which are referenced by name in metric events, dashboards, and SLOs.

RUM metrics live in Grail and follow a different naming scheme. Classic metrics use the builtin:apps.* prefix (for example, builtin:apps.web.actionDuration.*, builtin:apps.web.countOfErrors); the replacing RUM metrics use the dt.frontend.* prefix (for example, dt.frontend.user_action.duration, dt.frontend.error.count). The full mapping is documented in Upgrade from classic RUM metrics to Grail.

What to do

  1. Open Upgrade from classic RUM metrics to Grail and find the replacing RUM metric for each Classic metric you use in dashboards, alerts, or SLOs.
  2. For Classic metrics with no direct replacement, evaluate whether a DQL query covers the use case. If so, no metric is needed. See Upgrade data processing for guidance on creating custom metrics via OpenPipeline.
  3. Update any dashboard tiles, alert rules, or SLO definitions that reference Classic metric names to use the new RUM metric names. See Dashboards, Alerting, and SLOs below for details.

Key user actions

What changed

In RUM Classic, you designate specific user actions as Key User Actions per application. These actions receive dedicated monitoring: a separate performance waterfall view, dedicated built-in metrics (for example, builtin:apps.web.actionDuration.* filtered to that action), and the ability to trigger dedicated anomaly-detection rules scoped to a single action.

In RUM, any user action can be queried and visualized directly, including all its requests and waterfall analysis, so there is no need to pre-designate actions. You filter on the user action name, URL, or page name in DQL to achieve the same focus. To alert on specific user actions, you create custom alerts.

What to do

  1. List the Key User Actions you have defined in each Classic application (:settings: Settings > Web and mobile monitoring > [Application] > Key user actions) and note which dashboards or alerts depend on them.

  2. In Dashboards Dashboards or Notebooks Notebooks, build equivalent views using DQL. Filter fetch user.events on user_action.name or page.name to isolate the interactions that matter:

    fetch user.events
    | filter characteristics.has_user_action
    | filter startsWith(user_action.name, "click on checkout")
    | summarize count = count(), avgDuration = avg(duration) / 1000000

  3. Recreate action-specific alerts as custom alerts based on custom metrics. Extract a custom metric for the action from your user events with OpenPipeline (see Extract a metric from user events), then create a custom alert on that metric. See Alerting below for details.

Querying: USQL to DQL

What changed

Classic session analysis uses USQL (User Sessions Query Language), a SQL-like syntax targeting the usersession and useraction tables. RUM stores data in Grail; the query language is DQL (Dynatrace Query Language), and the main tables are user.sessions and user.events.

The two languages are conceptually similar but differ in syntax and capabilities. For an overview of all DQL commands, see DQL commands; for sorting and limiting results, see DQL ordering commands. The table below maps the most common USQL patterns to their DQL equivalents.

ConceptUSQLDQL

Table selection

SELECT … FROM usersession

fetch user.sessions

User action table

SELECT … FROM useraction

fetch user.events

Filtering

WHERE country = 'Austria'

| filter geo.country.iso_code == "AT"

Aggregation

AVG(duration), COUNT(*)

| summarize avg(duration), count() (duration is in nanoseconds)

Grouping

GROUP BY browser

| summarize count(), by: { browser.name }

Sorting

ORDER BY count DESC

| summarize count = count(), by: { browser.name } | sort count desc

Time series

Not available natively

| makeTimeSeries count = count()

What to do

  1. Review your existing USQL queries and note the use case each one covers. USQL queries can't run in RUM, so you can't paste them as they are.
  2. Recreate each use case in DQL in Notebooks Notebooks or Dashboards Dashboards. Use the mappings above, and use fetch user.sessions for session-level queries and fetch user.events for action- or event-level queries. Dynatrace Assist can help you turn a use case into a DQL query.
  3. Get started from existing content. The ready-made dashboards and the in-app charts in Experience Vitals Experience Vitals show typical DQL queries. You can open any chart in Dashboards Dashboards or Notebooks Notebooks to see and adapt its query.
  4. Save frequently used queries as notebook sections or dashboard tiles for reuse.

The DQL editor in Notebooks Notebooks provides field-name completion as you type. Start with fetch user.sessions | limit 1 to see the available session fields, then type a field name after fields to get suggestions.

Dashboards

What changed

RUM Classic automatically generates built-in application dashboards (overview, user behavior, web vitals, errors) for each application you configure. These dashboards are pre-built and use Classic metric names.

RUM provides various ready-made dashboards and notebooks on Grail that you can open from Experience Vitals Experience Vitals (see Experience Vitals), Users & Sessions Users & Sessions (see Users & Sessions), or by browsing the list of ready-made dashboards in Dashboards Dashboards. For custom views, build your own in Dashboards Dashboards and Notebooks Notebooks by copying tiles from the ready-mades, adding metrics with Add > Metrics, or writing DQL queries.

What to do

  1. Identify which Classic application dashboards you use regularly and note the metrics and filters they display.

  2. Check whether one of the ready-made dashboards or notebooks linked from Experience Vitals Experience Vitals or Users & Sessions Users & Sessions, or listed in Dashboards Dashboards, already covers your use case. Use it as is or as a starting point.

  3. Recreate custom tiles. If a tile is based on a built-in metric, copy the tile from a ready-made dashboard or add it with Add > Metrics (see Explore data). No DQL is required. If it is based on user events or sessions, use DQL: makeTimeSeries for time-series tiles and summarize for KPI tiles:

    fetch user.sessions
    | makeTimeSeries sessions = count(), interval: 1h

  4. To filter by frontend, use frontend.name:

    fetch user.sessions
    | filter in(frontend.name, "My Web App")

  5. Share completed dashboards with your team using the dashboard sharing settings in Dashboards Dashboards. For details, see Share documents.

Alerting

What changed

In RUM Classic, alerting is based on anomaly detection rules and custom metric events configured per application. Rules target Classic metric names and trigger Davis AI problems.

In RUM, you configure health alerts per frontend in Experience Vitals Experience Vitals. Health alerts use Dynatrace Intelligence anomaly detection (static threshold, seasonal baseline, or auto-adaptive) on key metrics such as Core Web Vitals, user action duration, request errors, exceptions, crashes, app start duration, ANR, and traffic drops and spikes. They trigger problems in Problems app - new Problems. For cases that health alerts don't cover, you can create custom alerts on Grail-stored RUM metrics by their new names.

What to do

  1. List your existing anomaly detection configurations: Settings Settings > Anomaly detection > Real user monitoring applications.
  2. Enable health alerts. For alerts on key metrics that health alerts cover (for example, Core Web Vitals, request errors, crashes, or user action duration), configure a health alert for each frontend. See Health alerts for frontends for the available alert keys and steps.
  3. Create custom alerts where required. For alerts that health alerts don't cover:
    • If an equivalent RUM metric exists, find it in Upgrade from classic RUM metrics to Grail and recreate the alert as a custom alert in the Anomaly Detection - new Anomaly Detection app (see Anomaly Detection app), referencing the new metric name.
    • If no built-in metric equivalent exists, first extract a custom metric from your user events or sessions with OpenPipeline (see Extract a metric from user events and Extract a metric from user sessions), then create a custom alert on that metric.
  4. Disable Classic anomaly detection. After you have validated the equivalent RUM alerts, disable the Classic rules for the frontend.

Classic anomaly detection rules continue to fire on Classic data while both modes run in parallel. Disable them for a given frontend only after you have validated the equivalent RUM alert.

SLOs

What changed

Classic SLOs are defined in SLOs Classic Service-Level Objectives Classic using USQL expressions as the numerator (good events) and denominator (total events). New SLOs use DQL metric queries in SLOs Service-Level Objectives.

What to do

  1. Open SLOs Classic Service-Level Objectives Classic and note the USQL expressions and target values for each SLO you maintain.
  2. In SLOs Service-Level Objectives, select Service-level objective and define the SLI with a custom DQL query that returns the sli field (see Create service-level objectives). You can query user events or sessions directly with fetch user.events or fetch user.sessions. If you need the SLI as a time series, for example for long-term trending, extract a custom metric instead (see Extract a metric from user sessions).
  3. Set the same target and warning thresholds as your Classic SLOs.
  4. Reconfigure alert notifications: map any existing SLO-breach notifications to the new SLO's alerting settings.

Session export

What changed

Classic session data can be exported via the USQL REST API (GET /api/v1/userSessionQueryLanguage/table) or streamed via Dynatrace event forwarding. Both use Classic data fields and schema.

RUM session data lives in Grail. It is accessible via the DQL REST API and can be forwarded to cloud object storage via OpenPipeline forwarding. The endpoint, query language, and field names all differ from Classic.

DQL REST API endpoint:

POST https://{your-tenant}/platform/storage/query/v1/query:execute

Request body:

{
  "query": "fetch user.sessions | filter in(frontend.name, \"My Web App\") | fields dt.rum.session.id, user.identifier, duration, geo.country.iso_code",
  "requestTimeoutMilliseconds": 5000
}

Durations are returned in nanoseconds, while USQL durations were in milliseconds. user.identifier is hidden by default; the query returns it only if you have the builtin-sensitive-user-events-and-sessions fieldset permission.

OpenPipeline forwarding: Set up a forwarding configuration in OpenPipeline for the user sessions or user events scope. It forwards unprocessed or processed records to your cloud object storage (for example, Amazon S3 or Azure Blob Storage) in batches approximately once a minute. For details, see Forward data to cloud storage via OpenPipeline.

What to do

  1. Identify integrations that consume Classic session data via the USQL API (ETL pipelines, BI tools, data warehouses).

  2. For each integration, update the endpoint URL to the DQL REST API and rewrite the USQL query as a DQL expression targeting fetch user.sessions or fetch user.events.

  3. Update field name references to RUM field names. Classic fields such as userSessionId, browserType, and country correspond to Grail fields. For the exact field names, see User sessions and User events in the Semantic Dictionary.

  4. For streaming or near-real-time export, configure OpenPipeline forwarding instead of polling the REST API.

  5. Run both the Classic and RUM exports in parallel during the transition period to validate that the output matches before decommissioning the Classic integration.

Related topics

  • Upgrade from classic RUM metrics to Grail
  • Built-in RUM metrics
  • Health alerts for frontends
  • Extract a metric from user sessions
  • Extract a metric from user events
Related tags
Digital Experience