Troubleshooting RUM

Diagnose missing RUM data in Edge Delta: debug mode, endpoint 404s, token 401s, origin 403s, CSP blocks, ad blockers, and missing Core Web Vitals.

  5 minute read  

Overview

Start with debug mode: set debug: true in the SDK configuration, or add an ed_rum_debug key to the browser’s localStorage, and the SDK logs its whole pipeline to the console. The localStorage switch works on a deployed page, so production can be diagnosed without a config change or a redeploy.

Most issues are also visible in the browser’s developer tools: check the network tab for the POST requests to /otel/v1/traces (views) and /otel/v1/logs (errors), and the console for script errors and CSP violations.

The following table summarizes the most frequent symptoms:

SymptomLikely cause
No span after loading a pageThe page was never hidden. View spans are sent when the visitor leaves or backgrounds the page.
404 on the ingestion requestThe endpoint value includes a path. Give it scheme and host only.
401 on the ingestion requestThe token is wrong or disabled.
403 on the ingestion requestallowed_origins does not include this origin.
No request fired at allinit never ran, a CSP or ad blocker blocked the script, or a wrong SRI hash blocked the bundle.
Data from some users onlyAd blockers block the script or the ingestion domain for a share of visitors.
No route change views in a single page applicationOnly a path change opens a view; query string rewrites do not.

No data appears

Work through these checks in order:

  1. Make sure you left the page. View spans are sent on hide because CLS and INP are only final then, so a tab you never switched away from has sent nothing yet. Errors are not held back this way and arrive within a few seconds.
  2. Check the browser’s network tab for a POST to /otel/v1/traces or /otel/v1/logs and match the status code against the following causes.
  3. If no request fired at all, confirm init runs with a token (in a bundler install, rumConfig is null when no token was configured), check the console for a CSP violation or an SRI error, and try with ad blockers disabled.

The status code on a failed request identifies the cause:

StatusCause and fix
404The endpoint value already ends in a path such as /traces. The Edge Delta interface lists full URLs for its own ingestion formats, but this SDK sends OTLP and appends the path itself. Set endpoint to just the scheme and host, or to the prefix your proxy serves at.
401The token is wrong or disabled. Copy the ingestion token from the pipeline again.
403allowed_origins on the HTTP ingestion node does not include this origin. Compare exactly, including scheme and port.

The following example shows a 403 in the network tab: the request preview carries the message This token is not allowed to be used from this origin, which means the page’s origin needs to be added to allowed_origins:

Browser network tab showing a 403 response because the page origin is not in the allowed origins list Browser network tab showing a 403 response because the page origin is not in the allowed origins list

A Content Security Policy blocks it

If the site sets a CSP, script-src has to allow https://js.edgedelta.com for the SDK bundle, and connect-src has to allow your endpoint host. The loader file is same-origin, so script-src 'self' already covers it, which is the reason the loader is a file rather than an inline script. Either block shows up as a CSP violation in the console and as nothing at all in Edge Delta. See Content Security Policy.

Data arrives from some users but not others

Ad blockers block RUM scripts and ingestion domains by default. This typically costs 10 to 30 percent of traffic and looks like a quiet shortfall rather than an error.

To recover the missing share, serve the bundle from your own domain and set endpoint to a first-party path that proxies to Edge Delta. See the endpoint option in RUM Configuration and API.

No data during local development

http://localhost:3000 is a distinct origin. If the pipeline restricts origins, add your local origin to allowed_origins, or point local builds at a pipeline node without the restriction.

Error stacks are minified

This is expected today. Source map support has not shipped yet, so stacks arrive as the browser produced them. Set the version option now so stacks can be tied to a build and symbolicated retroactively once source map support lands.

Core Web Vitals are missing on some views

This is normal. CLS and INP are only known once a visitor interacts with the page and the view ends, so a bounce can produce a documentLoad span with no INP. A phase attribute such as ed.rum.dns_ms is also absent when the phase did not happen, for example on a reused keep-alive connection. See the RUM Data Reference for which attributes are optional.

No route change views in a single page application

The SDK opens a view only on a change of path. A router that rewrites the query string on every filter or tab change does not produce views, by design. If the application should count something else as a view, drive views yourself with startView and endView; see Views.

Frontend traces are not linked to backend traces

Joining needs requestSpans: true, which sends a traceparent header on the page’s HTTP requests. Same-origin requests then join with no further setup. For a cross-origin API, the server must allow the traceparent header via CORS first, and then the host goes in propagateTo; in that order, because a server that does not allow the header rejects the preflight and the request never leaves the browser. The page load itself joins through a Server-Timing header instead. See Connect browser traces to backend traces.

Errors and views from the same page are always joined to each other by trace ID, with no configuration.

See Also