dynatrace/dynatrace-for-aiApache-2.013 files

Dt Obs Frontends

Real User Monitoring (RUM) on Dynatrace — web and mobile frontends. Core Web Vitals, user sessions, page performance, mobile crashes, frontend errors, and frontend-backend linking. Query via `user.events`, `user.sessions`, and `dt.frontend.*` metrics. Does NOT cover synthetic monitoring (HTTP/browser/network checks) — that's a separate domain.

Specification
Skill ID
dynatrace/dynatrace-for-ai/dt-obs-frontends
Publisher
dynatrace
Repository
dynatrace-for-ai
Installs
0
Files
13
License
Apache-2.0
Synced
Sep 23, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

dynatrace/dynatrace-for-ai/dt-obs-frontendsInstalls these files
  • SKILL.md
  • references/characteristics.md
  • references/csp-violations.md
  • references/error-tracking.md
  • references/frontend-backend-linking.md
  • references/mobile-monitoring.md
  • references/slow-page-load-playbook.md
  • references/troubleshooting.md
  • references/user-actions.md
  • references/user-sessions.md
  • references/visibility-changes.md
  • references/web-performance-analysis.md
  • references/web-vitals.md

What this skill tells the agent

Frontend Observability (RUM)

Monitor web and mobile frontends using Real User Monitoring with DQL. Targets RUM on the latest Dynatrace — do not use RUM Classic data.

Concepts and data model: https://docs.dynatrace.com/docs/observe/digital-experience/new-rum-experience/concepts

Data Model

Three data sources, each for a different question:

SourceUse forGranularity
timeseries dt.frontend.*Trends, dashboards, alertingAggregated metric
fetch user.eventsRoot cause, individual page views / requests / clicks / errorsPer-event
fetch user.sessionsBounce rate, session duration, session-level aggregatesPer-session

Rule of thumb: start with metrics for the shape of the problem, drill into events for the why. Use sessions when the question is about user journeys, not individual interactions.

Full event model: https://docs.dynatrace.com/docs/semantic-dictionary/model/rum/user-events

DQL language reference (functions, syntax, operators): https://docs.dynatrace.com/docs/platform/grail/dynatrace-query-language

*Key `dt.frontend. metrics** (all support dimensions: frontend.name, device.type, geo.country.iso_code, browser.name, os.name, dt.rum.user_type, dt.smartscape.frontend`):

  • dt.frontend.web.page.largest_contentful_paint / dt.frontend.web.page.interaction_to_next_paint / dt.frontend.web.page.cumulative_layout_shift / dt.frontend.web.page.first_input_delay — Core Web Vitals
  • dt.frontend.web.navigation.time_to_first_byte / dt.frontend.web.navigation.dom_interactive / dt.frontend.web.navigation.load_event_end — Navigation timing
  • dt.frontend.error.count — Error counts
  • dt.frontend.request.count / dt.frontend.request.duration — Request volume and latency
  • dt.frontend.user_action.count / dt.frontend.user_action.duration — User action volume and duration
  • dt.frontend.session.active.estimated_count / dt.frontend.user.active.estimated_count — Active sessions and users (cardinality metrics; use countDistinct() aggregation)

Common Filters

All sources (`user.events` + `user.sessions`):

  • frontend.name — frontend identifier (preferred for all filtering); array on user.sessions (session can span multiple frontends). dt.smartscape.frontend is the Smartscape entity reference — use it to access entity attributes such as tags or linked services, not for name-based filtering. Avoid querying Smartscape to resolve a name to an entity ID and then joining with user.events — always filter on frontend.name directly.
  • dt.rum.user_type — real_user, synthetic, robot
  • dt.rum.application.type — web or mobile
  • dt.rum.session.id, dt.rum.instance.id
  • os.name, geo.country.iso_code, client.isp
  • client.ip — client IP address (sensitive field — hidden by default; see Field Permissions below)

`user.events` — web only:

  • browser.name, browser.version, device.type

`user.events` — mobile only:

  • device.model.identifier, device.manufacturer, app.short_version

Common characteristic filters (scope user.events to a specific event type — use as | filter characteristics.has_X):

  • characteristics.has_page_summary — page loads (web)
  • characteristics.has_view_summary — views (SPA + mobile screens)
  • characteristics.has_navigation — navigation events
  • characteristics.has_user_action — user actions
  • characteristics.has_error — all errors

Full characteristics reference: references/characteristics.md

Field Permissions

Some fields are sensitive and belong to the builtin-sensitive-user-events-and-sessions fieldset. They are hidden by default on both user.events and user.sessions — users without access see null, and queries that filter or group by these fields silently return no results.

Sensitive fields used in this skill:

  • client.ip — client IP address
  • user.identifier — real user identity

Grant access with the following policy statement:

ALLOW storage:fieldsets:read WHERE storage:fieldset-name="builtin-sensitive-user-events-and-sessions"

Reference: Field permissions

Drill-Down Pattern

Most investigations follow this layered approach regardless of the specific problem domain (errors, performance, background activity, etc.):

1. Identify the frontend

Start by grouping by: {frontend.name} to find which application is affected. Filter by dt.rum.application.type (web or mobile) if you need to split web from mobile analysis upfront.

2. Find the affected page or view

Both fields are available on all events (not scoped to a specific characteristic):

  • page.name — the page URL normalised to a Dynatrace entity name; web only
  • view.name — the SPA route or mobile screen name; available on web and mobile

Both can be present on the same event. For web SPAs, page.name reflects the top-level document while view.name reflects the current route — grouping by view.name gives finer granularity. For mobile, use view.name only.

Additional narrowing dimensions

DimensionFieldPlatformWhen to use
Specific request / endpointurl.domain, url.pathweb + mobilePerformance or error pattern on a specific API call
Individual user sessiondt.rum.session.idweb + mobileReproduce a specific user's journey; connects to session replay
Device form factordevice.typeweb onlyDesktop vs mobile browser vs tablet pattern
Browser compatibilitybrowser.name, browser.versionweb onlyIssue only on certain browsers
App versionapp.short_versionmobile onlyRegression introduced in a specific app release
Geographygeo.country.iso_codeweb + mobileRegional infrastructure or CDN issue
Synthetic vs real trafficdt.rum.user_typeweb + mobileExclude synthetic monitors before user-facing analysis

Workflows

Each workflow maps to one or more references. Load the reference when you start the workflow, not upfront.

WorkflowReference
Event characteristics — types, filters, event_type derivationreferences/characteristics.md
Web Vitals (LCP, FCP, FID, INP, CLS)references/web-vitals.md
Session, bounce, engagement analysisreferences/user-sessions.md
User actions — interaction lifecycle, completion reasons, timeoutsreferences/user-actions.md
Errors, exceptions, failed requestsreferences/error-tracking.md
Frontend-backend linking — mechanisms, trace coverage, frontend.linkreferences/frontend-backend-linking.md
CSP violations — security policy enforcement and blocked resourcesreferences/csp-violations.md
Mobile app starts, crashes, ANR, native signalsreferences/mobile-monitoring.md
Request latency, long tasks, JS profiling, geo performancereferences/web-performance-analysis.md
Visibility changes — tab switching, background time, engagement qualityreferences/visibility-changes.md
Slow page load — backend vs render vs network vs JS triagereferences/slow-page-load-playbook.md
Diagnosing zero results, anomalies, ambiguous datareferences/troubleshooting.md

Performance Thresholds (quick reference)

  • LCP: Good < 2.5 s | Poor > 4.0 s
  • INP: Good < 200 ms | Poor > 500 ms
  • CLS: Good < 0.1 | Poor > 0.25

Use this skill in a project

Open any RiverX project, search the Skills panel for dynatrace/dynatrace-for-ai/dt-obs-frontends, and install it in one click.

Use this skill