After you add the App Check SDK to your app, but before you enable
App Check enforcement, you should make sure that doing so won't disrupt your
existing legitimate users.

An important tool you can use to make this decision for
Firebase AI Logic, SQL Connect, Realtime Database, Cloud Firestore, Cloud Storage, Authentication, Google Identity for iOS, Maps JavaScript API, and Places API (New) is the App Check request metrics screen.

In the Firebase console, you can view App Check request metrics for a
product in the **Security** \> **App Check** \>
[**APIs** tab](https://console.firebase.google.com/project/_/appcheck/products).
For example:

![Metrics page in the Firebase console](https://firebase.google.com/static/docs/app-check/app-check-metrics.png)

The request metrics for each product are broken down into four categories:

- **Verified** requests are those that have a valid App Check token. After
  you enable App Check enforcement, only requests in this category will be
  allowed.

- **Outdated client** requests are those that are missing an App Check
  token. These requests might be from an older version of your app before you
  added the App Check SDK.

- **Unknown origin** requests are those that are missing an App Check token,
  and don't look like they come from the Firebase SDK. These requests might be
  using stolen API keys, or they might be forged requests not using a
  Firebase SDK.

- **Invalid** requests are those that have an invalid
  App Check token, which might be from an inauthentic client attempting to
  impersonate your app, or from emulated environments.

- **Reused token** requests are those that have an App Check token which has
  already been used in a previous request. When
  [replay protection](https://firebase.google.com/docs/app-check/enable-enforcement.md.txt#replay-protection)
  is enforced, tokens can only be used once.

  > [!NOTE]
  > **Note:** Monitoring for replay protection is only available for Firebase AI Logic. Although replay protection for custom backends is also available (currently in beta), you need to set up your own monitoring solution.

The distribution of these categories for your app should inform when you decide
to enable enforcement. Here are some guidelines:

- **If almost all of the recent requests are from verified clients**: Consider
  enabling enforcement to start protecting your backend resources.

- **If a significant portion of the recent requests are from likely-outdated
  clients** : Avoid disrupting users, consider waiting for more users to update
  your app before enabling enforcement. Enforcing App Check on a released
  app will break prior app versions that are not integrated with the
  App Check SDK.

- **If your app hasn't launched yet** : Enable App Check enforcement
  immediately, since there aren't any outdated clients in use.

> [!IMPORTANT]
> **Important:** We recommend enabling App Check enforcement as early as possible so that all versions of your app are protected.  
> If you use Firebase AI Logic, it's particularly important to enforce App Check *before* you commit your app to a publicly available source code control system, share your app, or make your app publicly available.

## Next steps

When you understand how App Check will affect your users and you're ready to
proceed, you can
[enable App Check enforcement](https://firebase.google.com/docs/app-check/enable-enforcement.md.txt)
for Firebase AI Logic, SQL Connect, Realtime Database, Cloud Firestore, Cloud Storage, Authentication, Google Identity for iOS, Maps JavaScript API, and Places API (New).