# Deprecations (/en/docs/platform/monitoring/deprecation)





This page lists code that works today and will stop working on a future browser release. It is usually the smallest page in this section and the easiest to act on.

Each deprecated API is paired with its anticipated removal date, the document origin still calling it, and a report count:

<img alt="Deprecated API usage, each API paired with its anticipated removal date, the document origin still calling it, and a report count" src="__img0" width="1359" height="448" />

## Columns [#columns]

The report table has these columns:

| Column                  | What it means                                                            |
| ----------------------- | ------------------------------------------------------------------------ |
| **API**                 | The deprecated API, using the browser's own identifier                   |
| **Anticipated removal** | The version or date the browser plans to remove it, when it supplies one |
| **Document origin**     | The page that called it                                                  |
| **Browsers**            | Browsers that reported it                                                |
| **Reports**             | Reports collapsed into this row                                          |
| **Last seen**           | Most recent occurrence                                                   |

There is no disposition column here. The browser enforces nothing here. A deprecation is a warning.

## Prioritize the list [#prioritize-the-list]

Sort by **Anticipated removal** where dates exist and treat those as deadlines. For the rest, report volume is a reasonable proxy for how central the API is to your site.

A dash in Anticipated removal means unscheduled, not safe. Browsers often deprecate before committing to a date.

## Find the replacement [#find-the-replacement]

Drill into a row. The browser's own **message** normally names the replacement API, and browser vendors write these to be actionable.

API names are internal browser identifiers, not the names in your code. `XMLHttpRequestSynchronousInNonWorkerOutsideBeforeUnload` means synchronous XHR on the main thread. Searching the identifier finds the vendor's documentation and migration path.

## Third-party entries [#third-party-entries]

You cannot fix a vendor's code, but the entry still matters: their script will break on your site, and the browser will not distinguish their code from yours when it does. Track it and raise it with them.

## Monthly review [#monthly-review]

This is the only place a browser tells you about an outage in advance. Most teams discover an API was removed when a page breaks after a browser update, then spend the outage identifying what changed. A monthly pass turns that into scheduled work.

## Next steps [#next-steps]

* [Interventions](/en/docs/platform/monitoring/intervention)
* [Deprecation report reference](/en/docs/web-security/reporting-api/reports/deprecation)