Drafts a synthetic monitor configuration for one critical user journey - picks the platform (Datadog Synthetics, Pingdom, Checkly, New Relic, etc.), authors the scripted-transaction body (Playwright-style for browser checks; HTTP-step for API checks), wires the cadence (typical 1-15 min), defines per-step assertions (DOM presence, API status, response shape) and aggregate alert thresholds (consecutive-failure count + on-call routing). Includes the RUM-coverage gap method for deciding which journeys to monitor: score real-user journeys from RUM / CrUX data by session volume times business value, diff against the existing monitor inventory, and emit a ranked gap list. Use when a critical journey needs continuous-in-production verification per ISTQB-canonical shift-right ("a test approach to test a system continuously in production"), or when synthetic coverage was never systematically derived from real usage data.
70
88%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Per-source instructions for pulling the top-N journey inventory for the
RUM-coverage gap method in synthetic-monitor-author. Aim for the top 50 view
paths (or transaction names) by session volume to avoid chasing long-tail
pages with negligible traffic.
In the RUM Explorer (https://app.datadoghq.com/rum/explorer):
@view.url_path (or @view.name for SPAs with named routes).
Per Datadog RUM Explorer docs, "aggregate into groups
based on the value of one or several event facets" and "extract the count
of events per group" to get session volume per path.Query syntax shorthand: @view.url_path:* | count by @view.url_path | sort desc.
RUM Explorer supports key:value pairs where custom attributes require a
created facet first (Datadog RUM Search).
Open the Performance module and use the Trace Explorer to slice by transaction name. Per Sentry Transaction Summary docs, the platform surfaces throughput as TPM (transactions per minute) and TPS (transactions per second) per named transaction. Sort by Total throughput to surface highest-volume journeys. Export the table.
For public pages, the Chrome User Experience Report provides origin-level and
URL-level field data. Per CrUX methodology, pages must be
publicly discoverable (HTTP 200, no noindex) and meet a minimum visitor
threshold for statistical confidence; exact threshold is undisclosed. Access
via:
https://chromeuxreport.googleapis.com/v1/records:queryRecord)
for per-URL LCP, INP, CLS distributions.chrome-ux-report.all.<YYYYMM>) for bulk URL-level data.Per web.dev Core Web Vitals, the three stable metrics are:
All thresholds apply at the 75th percentile of page loads (web.dev CWV). CrUX field data is "the Google dataset of the Web Vitals program" (CrUX docs).