Intervention Reports

The browser overruled your page. It didn't ask first.

Browsers routinely decline to do what a page asked — blocking autoplay, refusing a heavy asset on a slow connection, ignoring a request they consider unsafe. Your code carries on as though it worked. Intervention Reports tell you where the browser and your intentions have parted company.

Start Free Trial Documentation →
What's at Stake

The page you tested is not always the page that ran.

Modern browsers act on the user's behalf, not the site's. When a page does something they judge harmful to performance, security or the experience, they quietly decline — and the page usually receives no error. Your build succeeded, your tests passed, your monitoring is clean, and a portion of your visitors are still getting a different site from the one you shipped, because their browser decided so on their behalf.

Silent Override

Declining isn't the same as failing

An intervention is not an exception. There is often no rejected promise and no error to catch, because from the browser's point of view nothing went wrong — it simply chose differently. Your error tracking has nothing to report.

Conditional

It depends on the device, network and user

Many interventions trigger on conditions you do not have: a slow connection, constrained memory, a user who has not interacted with the page yet. They are close to impossible to reproduce on a developer machine on a fast network.

Business Impact

The thing declined is often the thing that converts

Autoplaying product video, a deferred asset on a landing page, a request fired as the user leaves. Interventions tend to land on exactly the behaviour someone added deliberately to move a number, and nobody finds out it stopped happening.

What Intervention Reports Do

Find out where the browser is quietly saying no

One response header asks browsers to report the occasions they overrode your page. The reports come from real visitors on real devices, which is the only place these conditions genuinely occur.

Override Visibility

A record of what the browser refused to do

Each report names the intervention, the script and position that prompted it, and the page it happened on. Where the browser has a stated reason — performance, security, or the user experience — that comes too, so you can tell whether to work around it or accept the judgement.

Learn more about the Reporting API →
Real Conditions

Triggered by circumstances you can't reproduce

The conditions that provoke an intervention — a constrained device, a slow connection, a user who has not clicked anything yet — are precisely the ones absent from a developer machine and from most test environments. Real visitors encounter them constantly, and their browsers are the only reliable source of the finding.

Learn more about Crash Reports →
Third-Party Behaviour

Frequently it isn't your code being overruled

Embedded players, advertising tags and analytics scripts are common causes, because they are the parts of a page most likely to autoplay media, fire requests late, or load heavy assets regardless of conditions. Attribution to a source file tells you quickly whether this is yours to fix or theirs.

Learn more about Script Watch →
Get Started

See the site your visitors got. Not the one you shipped.

One header. No code. Reports arrive from real devices on real networks.

Start Free Trial Talk to our team →

30-day free trial  ·  One header  ·  No code  ·  Cancel anytime

Detection

The kinds of thing browsers intervene on

Interventions exist to protect performance, security and the user's experience. The specific list is decided by each vendor and changes over time — these are the categories you are most likely to encounter.

Category What the browser is doing
Media autoplay Refusing to start audio or video the user did not ask for
Network conditions Declining to load heavy assets on a connection judged too slow
Requests on unload Blocking work fired as the user navigates away from the page
Resource constraints Limiting behaviour on devices short of memory or battery
Security judgements Refusing an action considered unsafe in that context
Source attribution Which script and line prompted the intervention

Because each vendor decides its own interventions, the same page can be treated differently in different browsers — which is itself worth knowing.

Architecture

One response header. No code. No crawlers.

Intervention reporting is part of the browser, delivered over the Reporting API. Nothing of ours runs on your pages and no traffic is routed through us — the browser reports its own decisions to your endpoint.

One header enables the whole Reporting API. The same record covers intervention, deprecation and crash reports.

Minimal setup — the Reporting API endpoint
Report-To: {"group":"default","max_age":31536000,
  "endpoints":[{"url":"https://your-subdomain.report-uri.com/a/d/g"}]}

Your unique endpoint is on your Setup page once you have an account. Nothing else is required — the browser decides when it has overridden something worth telling you about.

No code added to your pages

No traffic routed through us

Captures conditions no test environment reproduces

Your site's performance is unaffected

The same header also enables deprecation and crash reports

Reporting API

Three report types, one deployment

The Reporting API is a single mechanism carrying several kinds of message from the browser. Intervention reports tell you the browser has already overridden what your page asked for. Deprecation reports warn that something is scheduled to stop working. Crash reports record sessions that ended when the browser gave out.

All three arrive through the same header, so once you have deployed it for one, the others cost nothing further.

Deprecation Reports →
Scope

One layer in the stack. Here's how it fits.

Intervention Reports describe decisions the browser has already made. They do not warn you about future removals and they do not catch ordinary errors — this is the present-tense signal, and it works alongside the rest.

Intervention Reports do Pairs with
Record behaviour the browser overrode Deprecation Reports for features scheduled to be removed
Attribute the cause to a script Script Watch for the inventory of what those scripts are
Surface device and network conditions Network Error Logging for visitors who never arrived
Reveal gaps between shipped and delivered Crash Reports for sessions the browser terminated

Together, these use the browser's own reporting to describe what your visitors experienced, rather than what your servers believe they served.