Power BI alerts watch the tile, not the pipeline
Power BI alerts are threshold-based notifications in Power BI Service. When a value on a dashboard tile crosses a boundary you define, Power BI sends you an email. One tile, one threshold, one recipient. That is the full scope of the feature.
The alerting itself works as documented. The problem is what it leaves uncovered.
You pin a card showing daily revenue to the executive dashboard, set the threshold at €50K, and move on. Three weeks later, the Databricks job that prepares the sales data fails at 02:00. The ADF pipeline downstream completes with zero fresh rows. The Power BI dataset refresh runs on schedule and succeeds, because the underlying table still exists with yesterday's data. The revenue card shows €127K. No threshold was crossed. No alert fired.
Your CFO opens the dashboard at 09:00 and shares a slide in the board meeting. The data is 36 hours old. Nobody finds out until someone manually checks the pipeline logs after lunch.
How native Power BI alerting actually works
Open a dashboard in Power BI Service. Hover over a card, gauge, or KPI tile, click the ellipsis (…), and select "Manage alerts." Define a condition (above, below, or equal to a value), set a threshold, and choose how often Power BI should evaluate it. Maximum frequency: once per hour. Save. Done.
The alert runs after each scheduled dataset refresh. If the tile's value crosses your threshold, you get an email and a notification in the Power BI notification center (the bell icon, top right). If the value stays within the boundary, nothing happens. There is no trending, no anomaly detection, no comparison to yesterday's value.
The alert email itself is minimal: a subject line like "Data alert for [tile name]," the current value, your threshold, and a link to the dashboard. No context about why the value changed. No upstream pipeline status. No refresh timestamp.
Prerequisites: Power BI Pro, Premium Per User (PPU), or a workspace backed by Premium or Fabric capacity. Free-tier users cannot create data-driven alerts.
One source of confusion since Microsoft Fabric launched: alerts still require a Pro, PPU, or Premium workspace. Fabric's free tier includes read access to reports but does not enable data-driven alerting. If you are unsure, check your workspace license type under Settings.
Where the notification goes and who gets it
Native alerts deliver through two channels:
- Email to the person who created the alert. Only that person.
- The Power BI notification center inside Power BI Service.
No native integration with Microsoft Teams, Slack, Telegram, or PagerDuty. No webhook endpoint. No distribution list.
If you want the alert to reach your data engineering channel in Teams, you need Power Automate. Create a flow that triggers on a Power BI alert and posts a message to a Teams channel, sends a second email to a shared mailbox, or calls a webhook. It works, but it is a separate system to configure and maintain. The alert itself still evaluates tile thresholds only.
The Power BI mobile app also receives push notifications for alerts if you have enabled them. Same constraint: only you, only threshold-based, only after a dataset refresh.
Five things Power BI's native alerts won't catch
1. Report visuals and paginated reports Alerts work on dashboard tiles only: card, gauge, and KPI visuals that have been pinned from a report to a dashboard. A matrix, a table, a bar chart, a decomposition tree, a paginated report — none of these support data-driven alerts. If your most critical metric lives in a report page that has not been pinned as a card to a dashboard, you cannot alert on it natively.
2. Refresh failures A failed dataset refresh does not trigger a data-driven alert. The tile keeps showing the last known value. Power BI has separate notification settings for refresh failures (under dataset settings, scheduled refresh section), but these are a completely different mechanism. You enable refresh failure emails per dataset, and they go to the dataset owner. They do not integrate with the alert management UI, and there is no consolidated view of "which of my 40 datasets had refresh failures today."
3. Volume anomalies and data completeness A dataset that loaded 0 rows instead of 50,000 will not trigger an alert unless the metric on the tile happens to cross your threshold. A pipeline that drops 3 columns because of a source schema change will not trigger anything either. There is no native concept of "the row count dropped 95% from yesterday" or "this table had 12 columns yesterday and now has 11." These silent data failures are the most damaging because every system reports success while the data is wrong.
4. Team routing The notification goes to one person: the alert creator. No team distribution, no on-call rotation, no escalation path. For a personal dashboard this is fine. For a production dashboard that three departments rely on, it is a single point of failure. If the alert creator changes roles or leaves the company, the alert still fires to an inbox nobody reads.
5. Evaluation speed Power BI checks the tile value at most once per hour, after a scheduled dataset refresh. For datasets on a 30-minute refresh cycle, you can wait up to 60 minutes after the threshold was actually crossed before the email arrives. Streaming datasets and DirectQuery have different mechanics, but for import-mode datasets (the majority), hourly evaluation is the ceiling.
Power Automate as the middle ground
Power Automate sits between native alerts and a full monitoring platform. You can build flows that trigger on a Power BI dataset refresh failure and post to a Teams channel, or run on a schedule to query a dataset via the REST API and notify when a value looks off, or chain checks across ADF and Power BI in a single flow.
The upside: it is part of your Microsoft 365 stack, it handles the "who gets notified" problem well (Teams channels, shared mailboxes, webhooks), and it can catch refresh failures that native alerts miss entirely.
The downside: you are assembling a monitoring system from individual flow components. Each pipeline-to-dashboard dependency is a separate flow. There is no lineage map, no anomaly baseline, no automatic correlation between an upstream ADF failure and a downstream dashboard impact. If your ADF pipeline fails and you want to know which Power BI datasets are affected, you build that mapping yourself, in each flow, for each pipeline.
For a team with 5 dashboards and 3 pipelines, this is practical. For a team with 40 dashboards, 15 ADF pipelines, a Databricks workspace, and a dbt project, the number of flows grows faster than anyone can maintain them.
When the alert needs to span the full pipeline
Power BI alerts watch the last mile: the number on the tile. Power Automate extends that to refresh failures and custom routing. Neither watches the complete data pipeline from source to dashboard.
Consider a pattern we see regularly across MetricSign users. A Databricks job preparing sales data ran 45 minutes late last Tuesday. The ADF pipeline that copies the Databricks output to the warehouse started on schedule and hit a truncated source table. The Power BI dataset refreshed on time with stale data from the previous day. The revenue card showed €127K. No threshold crossed. No Power Automate flow caught the Databricks delay because nobody had built a flow for that specific dependency.
MetricSign reads the activity logs from each layer: Databricks job runs, ADF pipeline runs, dbt model runs, and Power BI dataset refreshes. It maintains a lineage graph that maps which Power BI datasets depend on which upstream jobs. When the Databricks job ran late, MetricSign checked the lineage, identified two affected Power BI datasets scheduled to refresh within the next hour, and sent a Telegram message to the data engineering channel at 06:18, twenty minutes before the scheduled refresh. The engineer delayed the Power BI refresh. The dashboard showed correct data at the morning standup.
This is not a replacement for threshold alerts. If you need "notify me when revenue drops below €50K," use the native Power BI feature. MetricSign watches the data pipeline that feeds the tile: is the data late, incomplete, or sourced from a failed job? It catches the problem before the card even refreshes.
MetricSign connects to Power BI, ADF, Databricks, dbt Cloud, dbt Core, Fabric, and Snowflake. Free to start, connects to your first workspace in under 15 minutes.
Which alerting approach fits your team
Native Power BI alerts work when you need a threshold notification on a single dashboard tile, the alert is for one person, and the dataset refreshes daily. Setup takes 3 minutes. No maintenance needed.
Power Automate makes sense when you need refresh failure notifications, the alert should reach a team channel, or you want conditional logic like "alert only on business days." Expect to build and maintain one flow per pipeline-to-dashboard dependency.
A cross-stack observability platform fits when your dashboards depend on upstream jobs in ADF, Databricks, dbt, or Snowflake. When you need to trace a dashboard issue back to the upstream job that caused it. When you want anomaly detection beyond simple thresholds: volume drops, freshness violations, schema drift. When your team manages more than 10 production dashboards and cannot maintain individual Power Automate flows for each dependency.
The three approaches are not mutually exclusive. Many teams run native alerts for known thresholds, a few Power Automate flows for refresh failures, and an observability platform for the cross-stack lineage that neither provides on its own.