> For the complete documentation index, see [llms.txt](https://docs.powermonitor.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.powermonitor.com.br/en/perguntas-frequentes/duvidas-gerais/como-funciona-o-monitoramento-proativo.md). # How does proactive monitoring work? How Power Monitor checks your environment continuously, how often, and how alerts reach you. Power Monitor monitoring is **continuous and automatic**: you do not need to open the system to find out that something failed. Power Monitor queries your tenant through the official Microsoft APIs in regular cycles and, when it detects a problem, **opens an incident and sends an alert** to the configured recipients. When the problem is resolved, it sends the **resolution** notice. ### What is checked, and how often? | Situation | How it is detected | Approximate frequency | | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | --------------------- | | **Semantic model refresh failure** | Refresh history of the models on capacity, in all monitored workspaces | Every 15 minutes | | **Fabric item failure** (data pipeline, notebook, Copy job, Dataflow Gen2) | Runs that end with failure or cancellation | Every 2 hours | | **Gateway offline** | Status of each gateway on which the Power Monitor application is an administrator | Every 5 minutes | | **Capacity usage limit** | Accumulated capacity usage, read from the Fabric Capacity Metrics app, equal to or above **80%** | Every 5 minutes | | **High background usage** | Background consumption by thresholds (50%, 70%, 80%, and 100%) | Every 5 minutes | | **Consumption data unavailable** | No new capacity consumption data for more than 45 minutes (for example, paused capacity or metrics source unavailable) | Every 5 minutes | | **Consumption anomaly by item** | An item's consumption above the baseline of the last 7 days | Every 5 minutes | | **Execution time deviation** (optional, per item) | A run much longer than the item's average | Every hour | | **Capacity cost** | Daily cost above the average of the last 30 days plus the configured percentage | Daily | | **Capacity running outside business hours** | Capacity active outside the configured window | Every 5 minutes | | **Data freshness** and **Fabric Mirroring** | Monitors configured per item (maximum data delay, mirroring state) | Every 10 minutes | In addition to event alerts, there is the **Daily Checklist** (a daily summary of the environment) and the **Hourly Checklist** (sent only when there is an occurrence). {% hint style="info" %} Only **monitored workspaces** generate refresh and Fabric item alerts. See [Workspaces](/en/power-monitor/governanca/workspaces.md). {% endhint %} ### Which channels deliver the notifications? The channels are configured by an administrator in **Settings › Alerts**: * **Email**, through the Power Monitor server or through an **SMTP account** of your own company; * **Microsoft Teams**, through the Power Monitor bot installed in the chosen team and channel; * **Slack**; * **Telegram**. ### Can I choose which alerts to receive? Yes. In **Settings › Notifications**, the administrator chooses **which alert types** each recipient receives and can **Test** the delivery. In addition: * users with a **workspace scope** receive only the alerts for the workspaces they are linked to (alerts without a workspace, such as gateways and capacities, go to all eligible recipients); * **execution time deviation** is enabled item by item; * the **consumption floor** for anomalies and the **percentage** of the cost alert are configurable. {% hint style="warning" %} Today Power Monitor does **not** have quiet hours (a window without notifications) or generic webhooks. The 80% threshold of the capacity usage alert is fixed. {% endhint %} ### What if the problem persists? For gateways, semantic models, and Fabric items, the email is sent **when the incident is opened and when it is resolved**; recurrences while the incident is open are counted and appear in the **Hourly Checklist**. For the capacity usage limit, reminders continue while the situation persists. All alerts are recorded in **Monitoring › Alerts**. ### Does monitoring work 24/7? Yes. The checks run continuously, 24 hours a day, 7 days a week, including outside business hours. ### Want our team to act on the alerts? Power Tuning offers [Managed Monitoring](/en/managed-monitoring/monitoramento-gerenciado.md), in which our team acts on the critical alerts of your environment, with a 2-hour SLA for the first response. ### Related pages * [Alerts](/en/power-monitor/monitoramento/alertas.md) * [Settings](/en/power-monitor/configuracoes.md) * [Real-time alerts](/en/principais-funcionalidades/alertas-em-tempo-real.md) --- # 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.powermonitor.com.br/en/perguntas-frequentes/duvidas-gerais/como-funciona-o-monitoramento-proativo.md?ask=&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.