# Intervention (/en/docs/web-security/reporting-api/reports/intervention)



An `intervention` report tells you the browser declined to do something the page
requested because it would harm the user experience, performance, or battery. A
common example is blocking audio that tries to autoplay without a user gesture. The
report names what was intervened on and where in the code it came from.

<Callout type="warn" title="Experimental">
  Intervention reporting is a draft, implemented mainly in Chromium. Behavior and the set of interventions can change.
</Callout>

## When the browser sends it [#when-the-browser-sends-it]

When the browser applies an intervention, refusing an action the page asked for in
the user's interest (blocking autoplay without a gesture, throttling a heavy
operation). It is delivered to [the default reporting endpoint](/en/docs/web-security/reporting-api/concepts/default-endpoint) and is also observable
in the page through [`ReportingObserver`](/en/docs/web-security/reporting-api/concepts/reporting-observer).

## Payload example [#payload-example]

```json
{
  "type": "intervention",
  "age": 18,
  "url": "https://example.com/",
  "user_agent": "Mozilla/5.0 ...",
  "body": {
    "id": "AudioContextAutoplay",
    "message": "A request to play audio was blocked because it was not triggered by user activation.",
    "sourceFile": "https://example.com/player.js",
    "lineNumber": 1234,
    "columnNumber": 42
  }
}
```

Every `intervention` report body carries these fields inside the shared report envelope.

## Field reference [#field-reference]

| Field                         | Meaning                                                                         |
| ----------------------------- | ------------------------------------------------------------------------------- |
| `id`                          | A machine-readable identifier for the intervention, the stable key to group by. |
| `message`                     | A human-readable description of what was refused and why.                       |
| `sourceFile`                  | The file that triggered the intervention.                                       |
| `lineNumber` / `columnNumber` | The location in that file.                                                      |

## How to receive it [#how-to-receive-it]

Declare a `default` endpoint in [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints); interventions have no
per-policy directive. CentralCSP collects them with the rest of the report stream.

## What it tells you about security [#what-it-tells-you-about-security]

Interventions are mostly user-experience and performance signals rather than direct
security findings. They are still worth watching: a surge of interventions from a
script you did not write can be the first sign of unexpected or abusive third-party
behavior on the page.

## Gotchas [#gotchas]

The `id` is the stable key to track an intervention; the `message` wording can
change between browser versions, so group by `id`, not by text.

## Browser support [#browser-support]

Chromium-based browsers only; experimental. Other engines do not emit intervention
reports.

## See also [#see-also]

* [deprecation report](/en/docs/web-security/reporting-api/reports/deprecation)
* [ReportingObserver](/en/docs/web-security/reporting-api/concepts/reporting-observer)
* [Deprecation and intervention reports](/en/blog/deprecation-intervention-reports)
* [Intervention monitoring in CentralCSP](/en/docs/platform/monitoring/intervention)
* [Reporting-Endpoints header](/en/docs/web-security/reporting-api/headers/reporting-endpoints)
* [The report delivery format](/en/docs/web-security/reporting-api/concepts/report-delivery-format)

## Sources [#sources]

* [MDN, InterventionReport](https://developer.mozilla.org/en-US/docs/Web/API/InterventionReport)
* [MDN, Reporting API](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API)