Website Monitoring

Dash0's Website monitoring view gives you a comprehensive, real-time look into how users experience your website or web app, making it the ideal starting point for investigating frontend performance and behavior.

The visualizations offer high-level insights into page loads, user sessions, and web vitals, while powerful filters let you quickly narrow down by browser, location, route, or user. With rich contextual data like session traces, custom events, and performance metrics you can easily pivot to related views and uncover the root cause of issues from multiple angles.

Website Monitoring Overview showing

SDK

The Dash0 Web SDK is a JavaScript and TypeScript-compatible client designed to instrument web applications with observability data. It leverages OpenTelemetry under the hood to automatically track and report critical performance, user interaction, and network metrics. Upon initialization, the SDK begins monitoring key events such as page views, route transitions, HTTP requests, and errors. It also collects web performance metrics, known as Web Vitals, and handles session tracking seamlessly in the background.

To get started, developers integrate the SDK as early as possible in the application lifecycle. For example, in a React or Next.js app, the SDK is typically initialized in the main entry point. This ensures all subsequent activity is captured within the context of a single session. Once initialized, the SDK batches and sends telemetry to a Dash0 OTLP endpoint using a public ingest token.

Key Responsibilities:

  • Auto‑instrument page loads, route changes, HTTP requests, Errors, and Web Vital metrics
  • Associate events with user and session context
  • Batch and transmit telemetry to designed OTLP endpoint
  • Allow user-identification, custom events and attributes
TypeExplanationOpenTelemetry Signal
Page LoadTriggered when a page finishes loading completely. Measures time to load assets and render.Log/Event
Page TransitionCaptures changes between different pages or views in a Single Page Application (SPA).Log/Event
HTTPCaptures HTTP requests, responses, and associated latencies.Span
Web VitalCore performance metrics defined by Google: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Interaction to Next Paint (INP).Log/Event
Navigation TimingCaptures detailed browser timing metrics such as fetchStart, requestStart, response times, DOM events, and resource sizes (encoded/decoded/transfer).Log/Event
Custom EventsDeveloper-defined events to capture meaningful interactions that aren’t automatically recorded by the website monitoring SDK.Log/Event

User

In Dash0's data model, a User refers to a unique visitor to the website. Initially, the SDK assigns an anonymous user ID using local storage. This allows tracking across sessions even before authentication occurs. When the user logs in, developers can call the identify method to associate the current session with an authenticated user ID, providing continuity between anonymous and logged-in sessions.

User metadata can also be enriched with custom attributes such as email, account type, or role. These attributes help categorize user behavior and are valuable for segmentation in analytics dashboards. In addition to the ID, the SDK automatically captures environment data like browser, operating system, and locale, providing a full picture of the user context.

Session

A Session in Dash0 represents a single period of continuous user activity. The SDK automatically starts a new session when a user visits the site and continues it until there is a period of inactivity—typically 30 minutes—or the browser is closed. If the user returns later, a new session begins, even if it's the same anonymous or authenticated user.

Each session contains one or more page views and can include interactions, network requests, errors, and performance metrics. Sessions are key to understanding engagement, as they form the foundation for calculating metrics like session duration, bounce rate, and funnel progression. Developers do not need to manage session state directly; the SDK handles this automatically.

Session Identification

Each session is assigned a unique session ID, which is included with all telemetry data sent during that session. This ID allows Dash0 to:

  • Group page views, interactions, and performance metrics
  • Link session-level metadata such as duration, Web Vitals, and bounce status
  • Correlate with user identifiers (anonymous or authenticated)
session page with filters and session detail sidepanel

Session Lifecycle

The Dash0 SDK starts a new session when the user loads the site or application. By default a session ends with the first page load after either 3 hours of inactivity or a total duration of 6 hours, without a page load the session will continue beyond the specified limits.

The SDK uses cookies and localStorage (under the dash0_session and dash0_user keys) to persist session and user identifiers between page views and route changes.

Session Timeouts & Configuration via SDK

The Dash0 Web SDK exposes two settings for controlling session expiry:

  • sessionInactivityTimeoutMillis — the maximum time allowed without user activity (e.g. clicks, page loads) before a session expires. Defaults to 3 hours and must be less than the maximum session duration.
  • sessionTerminationTimeoutMillis — the maximum lifetime of a session. Defaults to 6 hours and likewise must be less than 24 hours

Use Cases

  • Tracking bounce rates (sessions with a single page view and no interactions)
  • Measuring session length and engagement levels
  • Associating Web Vitals to real usage journeys

Tab Tracking

Dash0 automatically tracks activity across multiple browser tabs within the same session. This ensures a complete picture of how users interact with your site, even when they switch between tabs in their browser.

Each tab is treated as its own context while still belonging to the same session. Events such as page loads, route transitions, and network requests are grouped under the tab in which they occurred. When a user switches tabs, Dash0 records a lightweight event, making it clear where context shifted.

This level of granularity helps developers:

  • Distinguish between parallel user journeys (e.g., browsing products in one tab and completing checkout in another).
  • Understand how tab switching impacts performance metrics like load times or Web Vitals.
  • Pinpoint errors or anomalies that only occur in background or secondary tabs.

In the session detail view, you can filter by tab to isolate a specific journey, or view them together in the Web Event explorer to analyze multi-tab behavior holistically. This makes it easier to follow complex user flows without losing continuity.

Session Detail view with highlights on Tab Tracking

Page View

A Page View is recorded every time a user navigates to a new page. In traditional websites, this happens on each full-page load. In modern single-page applications (SPAs), the SDK detects client-side route changes to log page transitions without requiring full reloads.

Page View TypeDescription
Page LoadA Page Load occurs when a user accesses a page for the first time or refreshes it entirely. It marks the beginning of a full page lifecycle, capturing metrics like load time, Web Vitals, and initial resource usage.
Page TransitionA Page Transition refers to a navigation event within a single-page application (SPA), where the route or view changes without reloading the entire page. It tracks changes in user context and helps monitor in-app navigation performance. Note: Updates to Web Vitals can be captured after the first Page Load

Each page view includes the URL, route name, referrer, page title, and timing data such as how long the page took to load. The SDK also associates Web Vitals with each page view, making it possible to analyze performance at a granular level. Page views are the cornerstone of user navigation analysis and allow developers to measure how users move through the site or application.

Web Vitals

Web Vitals are a set of standardized performance metrics designed to measure real-world user experience. Dash0 focuses on the three Core Web Vitals defined by Google, which are critical indicators of a website’s performance and user satisfaction.

These metrics are automatically collected by the Dash0 Web SDK using native browser APIs and OpenTelemetry instrumentation. Each metric is tied to individual page views and sessions, providing deep insight into how users experience your application in practice not just in lab conditions.

Web Vitals Detail Page LCP

Largest Contentful Paint (LCP)

LCP measures how quickly the main content of a page becomes visible to the user. It reports the render time of the largest visible element—such as an image, video, or text block—within the viewport. A fast LCP ensures that users perceive the page as loading quickly.

  • Good performance: ≤ 2.5 seconds
  • Helps identify slow-loading content, images, or render-blocking resources

Interaction to Next Paint (INP)

INP measures the responsiveness of your site by tracking the delay between a user's interaction (like clicking a button or typing) and when the UI updates on screen. It reflects the worst-case interaction latency during a session, replacing the older FID metric with a more comprehensive measure of interactivity.

  • Good performance: ≤ 200 milliseconds
  • Useful for pinpointing JavaScript blocking, slow animations, or sluggish event handlers

Cumulative Layout Shift (CLS)

​​CLS measures visual stability by calculating how often and how drastically elements shift on the screen while a page is loading or during interaction. A high CLS score typically results from unexpected layout changes, which can frustrate users or lead to mis-clicks.

  • Good performance: ≤ 0.1
  • Indicates problems with dynamic content, ad loading, or font shifts
  • Helps improve perceived polish and usability

Backend Trace Correlation

Dash0 automatically links frontend HTTP requests to backend traces, giving full visibility into the entire request lifecycle. By default, correlation is enabled only for requests that share the same origin as your website — but you can extend this to cross-origin requests with the correct setup.

In the session view, each HTTP request shows a “View full trace” option, enabling you to drill down into backend traces, including service-to-service calls, database queries, and more. This connection unlocks powerful use cases like:

  • Pinpointing where latency originates—whether in the browser, edge, or backend.
  • Tracing failed requests from the browser all the way into backend error logs and spans.
  • Identifying performance bottlenecks in APIs that directly affect the user experience.

By combining frontend monitoring with backend trace correlation, Dash0 delivers comprehensive, end-to-end observability across the full request journey.

Session Detail with Request Context

Custom Events

Custom Events allow you to capture specific user actions or application-level milestones that are relevant to your business logic, product goals, or feature usage. Unlike automatic events (such as page loads or fetch calls), custom events are manually defined and triggered by developers using the monitoring SDK.

Bounce Rate

The Bounce Rate is a metric that shows the percentage of sessions in which the user visited only a single page and took no additional actions. This typically indicates low engagement and can signal problems with page relevance, content quality, or performance.

In Dash0, a session is considered a "bounce" if it includes only one page view. Because the SDK tracks all of these automatically, bounce rate is calculated with high accuracy, even in single-page apps.

Reducing bounce rate often involves improving page content, speed, or encouraging users to interact through better UI design. Dash0 allows developers to dig into bounced sessions to understand where users are dropping off and why.

Geo Location

Geo Location data provides insight into where your users are accessing your site from. While the Dash0 SDK does not directly access browser-based location services (which would require user permission), it captures geographic metadata on the backend using the IP address of incoming telemetry.

This enrichment process adds fields such as country, region, city, and timezone to each event. These data points can be used to analyze geographic trends, monitor regional performance, or target users with location-specific content. For privacy and compliance, IP addresses are anonymized or hashed in accordance with GDPR and other regulations.

Geo-based segmentation is especially useful for identifying latency issues tied to specific regions, understanding market distribution, or monitoring localized deployments of global applications.

Last updated: September 25, 2025