> This page is for Applications Protection.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.humansecurity.com/llms.txt.

# Monitored Routes

In some cases, you might want to monitor a specific endpoint, and potentially pass traffic that should be blocked, even when the rest of your application is still in the **Active Blocking** mode. For example, in case of a change in the site topology, to prevent a possible false positive.

This feature allows you to configure specific routes that will go through the full Enforcer workflow. However, these routes will behave as if the Enforcer were in the **Monitor** mode rather than the **Active Blocking** mode. These routes will not be blocked, but they will generate risk and async activities. Any block activities will always be simulated blocks.

**TO define a monitored route:**

1. Open the **PX_CUSTOM.vcl** file.
2. Add the required route in the **px_custom_monitored_routes** cus**tom subroutine, as shown below**.

**EXAMPLE**

```javascript
sub px_custom_monitored_routes {
  if (req.url.path ~ {"^/prefix|^/exact/match$"}) {
     set req.http.X-PX-monitored-route = "1";
  }
}
```

\


To learn more about custom subroutines, see [Customized Subroutines](/applications/fastly-customized-subroutines).

**TO enable the feature:**

1. Open the **PX_CONFIG.vcl** file.
2. Set the **px_monitored_routes_enabled** value to "true" (enabled). The default is "false" (disabled).

```javascript
table px_configs {
  "px_monitored_routes_enabled": "true",
}
```

\


> **TEST**
>
> 1. Make sure your application is in the **Monitor** mode.
> 2. Send a request to one of the newly configured enforced routes, using Python 123 as the browser user-agent.
> 3. if you didn't get a CAPTCHA page, the feature is configured correctly.