[RUM] Core Web Vitals collection is dead — LCP/FCP dropped 55% → 0% of initial loads around 2026-07-04, blinding #1405

[dawsontoth]

Summary

Studio has not reported a single LCP or FCP measurement in over three weeks. Coverage of initial_load views collapsed from ~55% to exactly 0% around 2026-07-04 and has stayed there.

This means #1405 (open — "LCP performance regression: '/' view degraded +61.7%, 4320ms p75") can no longer be measured, confirmed, or closed, and no future LCP/FCP regression can be detected at all.

Surfaced by the automated daily RUM review (app f590deee-…).

Datadog findings

Coverage = share of @type:view @view.loading_type:initial_load events carrying the metric:

Metric	~2026-06-26 → 06-30	~2026-07-04 → 07-06	last 24h
@view.largest_contentful_paint	85/156 = 54.5%	0/61 = 0.0%	0/160 = 0.0%
@view.first_contentful_paint	89/156 = 57.1%	0/61 = 0.0%	0/160 = 0.0%
@view.dom_complete	98/156 = 62.8%	5/61 = 8.2%	39/160 = 24.4%
@view.loading_time	0/156 = 0.0%	0/61 = 0.0%	0/160 = 0.0%

@view.first_input_delay and @view.interaction_to_next_paint also return no data.

The signature is precise

dom_complete still works. LCP and FCP are exactly zero.

dom_complete comes from PerformanceNavigationTiming; LCP and FCP come from PerformanceObserver entries. Views are still being created and still carry navigation timings — so this is not a sampling, ingestion, or view-tracking outage. Specifically the paint-observer metrics stopped reaching the view.

A "0 out of 160" is not sparsity: at the old ~55% rate we'd expect ~88.

Narrowing the break

Two-day buckets put the transition between ~2026-07-02→07-04 (39.8% coverage) and ~2026-07-04→07-06 (0.0%):

window (rel. to 2026-07-28)	initial loads	with LCP	pct
32d → 28d	156	85	54.5%
28d → 26d	287	152	53.0%
26d → 24d	98	39	39.8%
24d → 22d	60	0	0.0%
22d → 20d	298	6	2.0%
18d → 16d	112	1	0.9%
14d → 12d	263	6	2.3%
8d → 6d	252	3	1.2%

(The residual 1–2% after the break is a handful of stragglers, presumably long-lived tabs on older bundles.)

Not the SDK. @datadog/browser-rum resolved to 7.4.0 on both sides of that boundary (7.2.0 Jun 19 → 7.3.0 Jun 22 → 7.4.0 Jun 29 → 7.5.0 Jul 13 → 7.6.1 Jul 27). Prod is currently on sdk_version:7.5.0. The break predates the 7.5.0 bump by ~10 days.

Likely mechanism

src/integrations/datadog/datadog.ts initializes with trackViewsManually: true, then starts a view twice during startup:

1. useDatadog (called from src/App.tsx) inits RUM inside a useEffect — i.e. after React mounts — and on onReady calls startView({ name: window.location.pathname || 'initial' }).
2. useOnRouteLoadTracker (called from src/components/StudioCloud.tsx) then calls startView again with the translated route name, on an effect keyed [location.href, router].

With trackViewsManually, Datadog attributes LCP/FCP to the initial view, and stops collecting once that view ends. If the second startView replaces the initial view before the browser settles the largest paint, both metrics are dropped — which matches the data exactly (paint observers zeroed, navigation timings unaffected).

Two commits in the bisect window plausibly changed that startup timing:

• 4f660718 (2026-07-03) fix(router): create the TanStack router once, not on every AppRouted render — the closest date match, and it directly changes the router identity that useOnRouteLoadTracker's effect is keyed on, hence when the second startView fires. (Context in CLAUDE.md under "the router must be created exactly once".)
• 7c5e9141 (2026-07-06) fix(auth): subscribe useRootAuthenticationContext once, not per change — also changes render/effect cadence around startup.

I want to be clear this is a hypothesis, not a proven cause — the correlation is by date and mechanism, and I could not reproduce paint-metric collection locally (it needs a production build and real page loads).

Suggested next steps

1. Confirm the mechanism with a production-mode build: init RUM, log datadogRum.getInternalContext() view ids across the two startView calls, and check whether the initial view ends before LCP settles.
2. Don't replace the initial view. Either drop the startView in useDatadog and let useOnRouteLoadTracker name the first view, or keep the initial view and only startView on subsequent route changes. One view per page load at startup, not two.
3. Consider initializing RUM outside a useEffect — at module scope in the entry, before React mounts — so the SDK's observers attach as early as possible.
4. Re-evaluate trackViewsManually: true. If it's only there for the friendly route names, @datadog/browser-rum-react's router instrumentation may give both naming and correct vitals.
5. Add a guard against silent loss: a Datadog monitor on LCP sample count per day would have caught this three weeks ago. Right now nothing alerts when a metric simply stops arriving.
6. Once fixed, revisit [RUM] LCP performance regression: '/' view degraded +61.7% in last 24h (4320ms p75) #1405 — its p75 baseline predates the break, so it needs fresh data before it can be judged.

Related

• [RUM] LCP performance regression: '/' view degraded +61.7% in last 24h (4320ms p75) #1405 (open) — the LCP regression this blinds. Depends on this being fixed first.
• [Perf] Page load time spike on main cluster view: 06:00–09:00 UTC June 25 #1377 (closed) — earlier page-load-time spike investigation, same metric family.

Filed by the automated daily Datadog RUM review. No PII or customer identifiers included.

[dawsontoth]

Root cause confirmed — and it's narrower than the hypothesis above

Fix in #1642. The mechanism is now read out of the installed SDK source (@datadog/browser-rum-core@7.8.0) rather than inferred, and reproduced against the shipped bundle.

Three facts settle it:

1. trackInitialViewMetrics runs only for INITIAL_LOAD views — trackViews.ts:267-270. LCP, FCP and navigation timings have exactly one possible home per page load.
2. The public startView() always creates a ROUTE_CHANGE view, after ending the current one — trackViews.ts:177-178.
3. With trackViewsManually: true the SDK stays stopped until the first startView, then adopts that call's options as the initial view and skips its callback so no extra view is created — preStartRum.ts:105-118.

So the SDK's contract is: call startView exactly once per page load. Studio called it twice — useDatadog and then useOnRouteLoadTracker — and the second call destroyed the only view that can carry paint metrics.

Reproduced

Served the shipped @datadog/browser-rum@7.8.0 bundle over HTTP, replicated Studio's boot sequence, and captured events in beforeSend (returning false, so nothing reached Datadog):

startView #1 (useDatadog)            t=78.2ms
startView #2 (useOnRouteLoadTracker) t=78.5ms   ← 0.3ms later, same effect flush

The initial_load event shipped with dom_complete: 79ms and no lcp, no fcp, then a route_change view took over. That matches production exactly — of 200 raw initial_load views over 7 days: dom_complete 17, fcp 2, lcp 0.

Two of the suggested next steps above are dead ends

• "Initialize RUM outside a useEffect, at module scope" would change nothing. Under trackViewsManually, init() does not start collection — the first startView() does (preStartRum.ts:105). Moving init earlier is inert.
• "Re-evaluate trackViewsManually" isn't necessary; the flag behaves correctly when called once.

Step 2 ("don't replace the initial view") was the right one, and is what #1642 does.

A second bug in the same five lines

useDatadog named the initial view from window.location.pathname — but Studio uses createHashHistory(), so that is permanently /. Production confirms it with no exceptions:

loading_type	view names (7d)
initial_load	/ — 880, a single bucket
route_change	/$organizationId/ 564, /$organizationId/$clusterId/ 494, / 437, …/apps/ 315, …

Every initial page load of every route was attributed to /.

This affects #1405. Its premise — "'/' view degraded +61.7%, 4320ms p75" — was not measuring the dashboard root; the / view was every deep-link entry conflated into one bucket. #1405 needs re-framing, not just fresh data once collection resumes.

One correction to the analysis above

The filed note reasoned that the second startView lands "before the browser settles the largest paint". True, but view.time_spent cannot be used to check that: on an initial_load view it is measured from clocksOrigin() — page origin, not SDK start. Production initial_load views show a median time_spent of ~1s, which looks like plenty of time and is not; the repro reports time_spent: 78ms for a view whose actual observation window was 0.3ms.

Caveat on verification, and what to watch after deploy

The fix is not proven end-to-end. Every browser surface available locally reports visibilityState: 'hidden', which emits zero paint and LCP entries — and trackFirstHidden (trackFirstHidden.ts:12-13) would discard them anyway. So vitals read as absent whether the fix works or not; confirming the restore needs a visible browser on a production build.

The cheap confirmation is to watch @view.largest_contentful_paint coverage on initial_load views after #1642 deploys — it should go from 0% to a non-trivial share. I'd keep this issue open until that is observed, which is why #1642 says Refs rather than Fixes.

Also worth noting for step 5 (the monitor): initial_load is only 879 of 7,125 prod views (12%), so an LCP sample-count monitor needs to be scoped to initial_load or it will be swamped by route_change views that never carry the metric.

Still open after #1642

A boot-time redirect can still fire two views: dashboardLayout.beforeLoad throws redirect({ to: '/sign-in' }) for a logged-out deep link (src/router/dashboardRoute.ts:11-19), so location.href changes twice during that boot and the tracker's effect — keyed [location.href, router] — can fire twice. I confirmed the redirect exists but not that StudioCloud mounts before it resolves, so it may or may not reproduce. Left out of #1642 deliberately (suppressing that second view risks losing genuine route_change tracking) and called out there for the reviewer.