Dt Obs Frontends
Run advanced Dynatrace DQL on frontend RUM data to find regional slowness, error correlations, and post-deploy regressions.
Overview
dt-obs-frontends is an agent skill most often used in Operate (also Grow analytics, Ship perf validation) that delivers advanced Dynatrace DQL for frontend performance, geo, and error correlation.
Install
npx skills add https://github.com/dynatrace/dynatrace-for-ai --skill dt-obs-frontendsWhat is this skill?
- Geographic distribution of request count and avg duration by country for CDN tuning
- Correlation timeseries linking error_rate_percent with avg_duration_sec per frontend.name
- Regression-oriented analysis after deployments comparing synthetic vs real user signals
- Ready-to-adapt DQL snippets with 1h–4h windows and volume filters (e.g. request_count > 50)
- Targets dt.frontend.request and dt.frontend.error metrics for advanced RUM workflows
Adoption & trust: 649 installs on skills.sh; 87 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your users report slow pages in some regions or more errors after a deploy, but default Dynatrace views do not show geo skew or duration-error coupling in one pass.
Who is it for?
Indie SaaS operators on Dynatrace RUM who need copy-paste DQL for CDN decisions and incident triage without hiring a dedicated observability engineer.
Skip if: Greenfield apps with no Dynatrace frontend ingestion or backends-only tracing with zero browser data.
When should I use this skill?
CDN optimization for regional performance, correlating performance with error rates, detecting regressions after deployments, or comparing synthetic vs real user performance.
What do I get? / Deliverables
You run documented DQL to rank regional slowness, flag high error_rate_percent alongside duration, and support regression checks after releases.
- Executed or adapted DQL for geo performance ranking
- Error-vs-duration correlation view for triage
- Evidence for post-deploy regression hypothesis
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Frontend performance and error signals matter most once traffic is live—Operate is the primary shelf for observability queries. Monitoring subphase holds DQL timeseries for duration, errors, and geo—beyond basic dashboard clicks.
Where it fits
Sort countries by avg_duration_sec after a CDN change to see if latency shifted offshore.
Filter apps with error_rate_percent above 5 while duration rises to narrow a bad release or third-party script.
Compare synthetic vs RUM signals right after deploy using the skill’s regression-oriented framing.
Reuse geo and error correlation queries in weekly funnel reviews tied to frontend.name.
How it compares
DQL recipe pack for dt.frontend metrics—not a generic Lighthouse-only local perf audit.
Common Questions / FAQ
Who is dt-obs-frontends for?
Solo builders and small teams using Dynatrace Real User Monitoring who want advanced geographic, correlation, and regression queries without building DQL from scratch.
When should I use dt-obs-frontends?
In Operate monitoring when investigating regional latency; after Ship perf checks post-deploy; in Grow analytics when tying frontend health to retention dashboards.
Is dt-obs-frontends safe to install?
The skill suggests read-only analytics queries; confirm your Dynatrace RBAC and review the Security Audits panel on this page before enabling agent-driven query execution.
SKILL.md
READMESKILL.md - Dt Obs Frontends
# Advanced Frontend Performance Analysis Advanced performance analysis including geographic distribution, correlations, and regression detection. **Use Cases:** - CDN optimization for regional performance - Correlate performance with error rates - Detect regressions after deployments - Compare synthetic vs real user performance ## Geographic Performance Distribution Compare request performance across regions: ```dql timeseries request_count = sum(dt.frontend.request.count), avg_duration = avg(dt.frontend.request.duration), by: {frontend.name, geo.country.iso_code}, from: now() - 4h | fieldsAdd app_name = frontend.name, avg_duration_sec = avg_duration / 1000 | filter request_count > 50 | sort avg_duration desc ``` **Use Case:** Identify geographic regions experiencing poor performance for CDN optimization. ## Performance vs Error Rate Correlation Correlate slow requests with error occurrences: ```dql timeseries request_count = sum(dt.frontend.request.count), error_count = sum(dt.frontend.error.count), avg_duration = avg(dt.frontend.request.duration), by: {frontend.name}, from: now() - 1h | fieldsAdd app_name = frontend.name, error_rate_percent = (error_count / request_count) * 100, avg_duration_sec = avg_duration / 1000 | filter error_rate_percent > 5 | sort error_rate_percent desc ``` **Use Case:** Identify if slow requests correlate with increased error rates. ## Request Performance Degradation Detection Monitor request duration trends for regressions: ```dql timeseries { avg_duration = avg(dt.frontend.request.duration), p95_duration = percentile(dt.frontend.request.duration, 95), request_count = sum(dt.frontend.request.count) }, by: {frontend.name}, from: now() - 24h, interval: 1h | join [ timeseries { prev_avg_duration = avg(dt.frontend.request.duration) }, by: {frontend.name}, from: now() - 24h, interval: 1h, shift: 1h ], on: { frontend.name }, fields: { prev_avg_duration } | fieldsAdd app_name = frontend.name, duration_change_percent = coalesce((avg_duration[] - prev_avg_duration[]) / (prev_avg_duration[]) * 100, 0) | filter duration_change_percent > 20 | sort duration_change_percent desc ``` **Use Case:** Detect performance regressions after deployments or infrastructure changes. ## User Type Performance Analysis Compare performance for different user segments: ```dql timeseries request_count = sum(dt.frontend.request.count), avg_duration = avg(dt.frontend.request.duration), p90_duration = percentile(dt.frontend.request.duration, 90), by: {frontend.name, dt.rum.user_type}, from: now() - 4h | fieldsAdd app_name = frontend.name, avg_duration_sec = avg_duration / 1000, p90_duration_sec = p90_duration / 1000 | filter request_count > 10 | sort dt.rum.user_type, p90_duration desc ``` **Use Case:** Ensure consistent performance across synthetic, real user, and robot traffic. # Content Security Policy (CSP) Violations Monitor and analyze Content Security Policy violations for security and compliance. **Data Source:** `fetch user.events` with `characteristics.has_csp_violation` **Key Fields:** - `csp.violated_directive` - Original policy directive violated - `csp.effective_directive` - Actual enforced directive - `csp.blocked_uri.*` - Blocked resource details - `csp.document_uri.*` - Page where violation occurred - `csp.disposition` - `enforce` (blocked) or `report` (logged only) ## All CSP Violations Query all CSP violations: ```dql fetch user.events, from: now() - 2h | filter characteristics.has_csp_violation == true | summarize violation_count = count(), affected_sessions = countDistinct(dt.rum.session.id), by: {frontend.name, csp.violated_directive} | sort violation_count desc ``` **Use Case:** Overview of CSP violation patterns. ## Violations by Blocked Resource Identify blocked reso