> For the complete documentation index, see [llms.txt](https://docs.adpage.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adpage.io/optimize-your-setup/pro-active-monitoring.md).

# Pro-active monitoring

How AdPage watches a client's tracking setup around the clock and alerts you the moment something breaks — instead of finding out weeks later.

### What does Pro-active Monitoring do?

Most tracking problems aren't discovered by looking at a dashboard — they're discovered when a client asks why their reported revenue looks wrong, sometimes weeks or months after a tag quietly stopped firing. Pro-active Monitoring closes that gap: AdPage continuously scans a container's tracking setup and automatically alerts the right people the moment something looks off, instead of waiting for someone to notice.

|                    | Without Pro-active Monitoring      | With Pro-active Monitoring            |
| ------------------ | ---------------------------------- | ------------------------------------- |
| **Checking**       | Manual, occasional                 | Automated, continuous                 |
| **Detection time** | Weeks to months                    | Within minutes                        |
| **Alerting**       | None — someone has to notice first | Automatic, sent straight to the inbox |

What gets scanned:

* Tag activity and status
* Incoming\_requests from platforms
* Platform delivery outgoing\_requests
* Webhook matching

{% hint style="info" %}
Pro-active Monitoring is a **Performance package** feature.
{% endhint %}

### Where to find it

Alerting is configured per container. Open your container, click **Monitoring** in the sidebar and open the **Proactive monitoring** tab (next to **Overview**, **Raw requests**, **History** and **Sent alerts**). For a tour of the other tabs, see [The Monitoring page](/optimize-your-setup/the-monitoring-page.md).

<figure><img src="https://1274044937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FufYZLteSPKQvntQZuDRu%2Fmonitoring-proactive-performance-en.webp?alt=media" alt="The Proactive monitoring tab with the Purchase, Duplicate, Consent and Platform alerts"><figcaption><p>The Proactive monitoring tab on the Monitoring page.</p></figcaption></figure>

### The alerts

Under **Your alerts** you see which alerts are on, for example *0 of 4 on*. Turn each alert on or off with its switch, and click **Edit** to change it.

| Alert               | When you get an email                               |
| ------------------- | --------------------------------------------------- |
| **Purchase alert**  | No purchase has come in for 3 hours.                |
| **Duplicate alert** | An order comes in as a purchase 1.10 times or more. |
| **Consent alert**   | Fewer than 40% of your visitors give consent.       |
| **Platform alert**  | A platform accepts fewer than 90% of your events.   |

When you turn on an alert and there is no recipient yet, your own address is added. We only email when there is a new problem, not every hour again. Every alert that was sent is listed on the **Sent alerts** tab.

### Setting up Pro-active Monitoring

{% stepper %}
{% step %}

#### Turn on alerts

Flip **Alerts activate** to on. This is the master switch — with it off, none of the settings below send anything, no matter how they're configured.
{% endstep %}

{% step %}

#### Choose the alert frequency

| Frequency | What it sends    | Availability                                                                                  |
| --------- | ---------------- | --------------------------------------------------------------------------------------------- |
| Hourly    | A short summary  | Performance package only                                                                      |
| Daily     | A daily overview | Performance package only                                                                      |
| Weekly    | A weekly report  | Available on any package — an admin can enable this manually for a client without Performance |

Only one frequency is active at a time.
{% endstep %}

{% step %}

#### Choose which alert types to send

Two toggles, independent of each other:

* **Critical Alerts** — tracking has completely stopped, or there's a serious data issue.
* **Warnings** — potential problems that need attention but aren't (yet) breaking anything.

A client can be on Critical-only if they only want to hear about the fires, or have both on for earlier warnings too.
{% endstep %}

{% step %}

#### Manage email recipients

Under **Email receivers**, each recipient has an on/off toggle so you can pause someone's alerts without removing them. One recipient is marked **Primary** and can't be deleted, only toggled — every other recipient can be removed with the trash icon. Add someone new by typing their address in the field at the bottom and clicking **Add.**
{% endstep %}

{% step %}

#### Save

Click **save** to apply the configuration. A green **Alerts active** confirmation summarises what the client will now receive.
{% endstep %}
{% endstepper %}

### Testing your alert configuration

There are two ways to test, and they check different things:

* **Send test email** — fires an unconditional test email to the current recipient list, regardless of the container's actual tracking status. Use this to confirm the alert emails actually arrive and aren't landing in spam.
* **Full validation + alert test** — runs a real check against the container and only sends an alert if it actually finds an issue. Use this to confirm the detection logic itself is working, not just email delivery.

Run the full validation after any tracking change you'd expect Pro-active Monitoring to catch, to confirm it actually gets flagged.

{% hint style="warning" %}
You can also setup Slack and Teams as delivery channels in addition to email.
{% endhint %}

If a client's alerting needs don't fit contact <support@adpage.io> with the container ID.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.adpage.io/optimize-your-setup/pro-active-monitoring.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
