# Reporting checker (/en/docs/platform/tools/reporting-api-checker)



The reporting checker fetches a live page, reads its reporting headers, and shows where each browser policy sends its violations. It names the endpoints the response declares, marks the ones nothing points at, and lists every policy that is present but reports nowhere.

Reporting fails quietly. A policy with a typo in its endpoint name still enforces, still blocks, and still sends nothing. This tool is how you find that out without waiting for reports that never arrive.

## Check a site [#check-a-site]

1. Open **Tools** > **Reporting checker**.
2. Enter the address, for example `example.com`.
3. Leave **Follow redirects** on unless you want the response at that exact URL.
4. Select **Check reporting**.

## Read the Reporting tab [#read-the-reporting-tab]

The score and the findings work the same way as in the other scanners, described on the [Tools overview](/en/docs/platform/tools). What is specific to this tool is the **Reporting** tab, which holds two tables.

### Reporting endpoints [#reporting-endpoints]

One row per endpoint the response declares.

| Column          | Means                                                          |
| --------------- | -------------------------------------------------------------- |
| **Endpoint**    | The name the endpoint is declared under, for example `default` |
| **URL**         | Where reports for that name are sent                           |
| **Status**      | `Used` if at least one policy points at it, `Unused` otherwise |
| **Declared in** | Which header declared it, `reporting-endpoints` or `report-to` |

An `Unused` endpoint is dead weight, and usually a sign that a policy names a different endpoint than the one you configured.

The **Declared in** column is where a legacy setup shows itself. [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints) is the current header. [`Report-To`](/en/docs/web-security/reporting-api/headers/report-to) is the deprecated one, and it is still the only header [Network Error Logging](/en/docs/web-security/policies/network-error-logging) reads its endpoint from, so a site that uses NEL keeps both.

### Reported features [#reported-features]

One row per policy the response carries.

| Column         | Means                                                                        |
| -------------- | ---------------------------------------------------------------------------- |
| **Feature**    | The policy, for example Content-Security-Policy or CSP script-hash reporting |
| **Present**    | Whether the response sends the policy at all                                 |
| **Reports to** | The endpoint URL its violations resolve to, or empty if it reports nowhere   |
| **Mode**       | `Enforced` if the policy blocks, `Report-only` if it only reports            |

The checker covers Content-Security-Policy, CSP script-hash reporting, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Permissions-Policy, Document-Policy, Integrity-Policy, Connection-Allowlist, and Network Error Logging.

## What the three states tell you [#what-the-three-states-tell-you]

Reading the two tables together gives you one of three answers per policy:

* **Present and pointing at a used endpoint.** Reports are being delivered. Check the **Mode** column next, because a report-only policy reports without blocking.
* **Present with an empty Reports to.** The policy is active and its violations go nowhere. Add a [`report-to`](/en/docs/web-security/policies/content-security-policy/directives/report-to) directive naming an endpoint you declared.
* **Missing.** The policy is not sent at all, so there is nothing to report.

A `Report-only` row across several policies is a common and deliberate state during a rollout. It becomes a finding because reported is not blocked, and a rollout left half-finished looks exactly the same from the outside.

## Verify your own endpoint [#verify-your-own-endpoint]

When you point a site at CentralCSP, the same check runs behind [Connect your site](/en/docs/platform/websites/connect-your-site) to confirm your headers reach us. Running the tool by hand is the way to re-check later, after a CDN change or a framework upgrade rewrites your headers.

## Next steps [#next-steps]

* [Connect your site](/en/docs/platform/websites/connect-your-site) to start collecting reports
* [Reporting API reference](/en/docs/web-security/reporting-api)
* [Header scanner](/en/docs/platform/tools/security-header-scanner), which includes the same Reporting tab
* [Tools overview](/en/docs/platform/tools) for sharing, exporting, and limits