Analyze Web Events

Dash0 automatically generates a set of built-in synthetic metrics from your telemetry. These appear alongside your own custom metrics in the Query Builder, as can be seen above. For example:

• dash0.web.eventsCopy — total count of all browser-side events captured (web vitals, errors, navigations, custom interactions).
• dash0.web.errorsCopy — count of client-side JavaScript errors and failed operations captured in the browser.
• dash0.web.requestsCopy — total number of outbound HTTP requests initiated from the browser (XHR, Fetch, etc.).
• dash0.web.requests.durationCopy — latency of outbound browser requests in milliseconds, from initiation to response.
• dash0.web.usersCopy — count of unique users observed within the telemetry window, derived from browser identifiers.
• dash0.web.vitals.lcpCopy — Largest Contentful Paint: time in milliseconds until the largest visible element is fully rendered; measures perceived load speed.
• dash0.web.vitals.inpCopy — Interaction to Next Paint: latency from a user interaction (click, keypress) to the next visible paint; measures responsiveness.
• dash0.web.vitals.clsCopy — Cumulative Layout Shift: score representing total unexpected layout movement during page load; measures visual stability.
• dash0.web.page_viewsCopy — number of distinct page views recorded across all sessions.
• dash0.web.sessionsCopy — total number of user sessions.
• dash0.web.sessions.durationCopy — duration of user sessions in milliseconds, from first event to last.
• dash0.web.bouncesCopy — count of sessions where the user left without any further interaction after the initial page load.

These metrics are also accessible directly in the Metrics and PromQL tabs, giving you the flexibility to combine them with your own metrics or apply custom aggregations.

Core Web Vitals are a set of metrics defined by Google that quantify real-user page experience. Dash0 uses the same thresholds as Google when colour-coding scores.

For threshold values and guidance on improving scores, see Web Vitals on web.dev.

• Focus on error events only. Filter by dash0.web.event.status.codeCopy = ERRORCopy alongside the Events total metric to isolate events that completed with an error status. Use UNSETCopy to see events where no explicit status was recorded.
• Scope to a single service. Filter by service.nameCopy = frontend-webCopy to restrict the query to browser telemetry from a specific frontend application — useful when multiple web properties report into the same environment.
• Narrow to a specific request. Filter by dash0.web.request.nameCopy = GET /api/cartCopy to measure the volume or duration of a single browser-initiated request — useful when investigating a specific API call that is slow or error-prone for real users.
• Focus on a specific page or route. Filter by dash0.web.event.titleCopy = GET /api/recommendationsCopy to scope the query to events associated with a particular page or endpoint, without switching to a Group by view.
• Isolate a single environment. Filter by deployment.environment.nameCopy = productionCopy to exclude staging or canary traffic from your baseline — especially important before creating a check rule where test traffic could cause false-positive alerts.
• Filter by HTTP response code. Filter by http.response.status_codeCopy = 500Copy to isolate requests that received a server-side error response, separating backend failures from client-side errors.

• Group by dash0.web.request.nameCopy to compare request volume or duration across all endpoints in a single chart — useful for identifying which API calls are the slowest or most error-prone for real users.
• Group by dash0.web.event.status.codeCopy alongside the Events total metric to visualise the split between successful and error events over time, and quickly detect when error events begin to grow.
• Group by service.nameCopy when multiple frontend applications report into the same environment, to compare their performance and error rates side by side.
• Group by http.request.methodCopy to separate GETCopy and POSTCopy request volumes — write operations often have very different latency profiles from reads and may warrant separate SLO thresholds.
• Group by error.typeCopy or exception.typeCopy alongside the Errors metric to break down frontend error volume by error class — useful for prioritising which error types to investigate first.
• For multi-dimension breakdowns, switch to the PromQL tab. Your current Web Events query is carried over and you can extend the byCopy clause manually — for example, to split by both service.nameCopy and dash0.web.event.status.codeCopy simultaneously.