Picture this: It's Monday morning at 9 AM. Your regional sales director opens the quarterly revenue dashboard just before a board presentation. The numbers look off — way off. After a frantic ten minutes, the team discovers the data hasn't refreshed since Thursday. The weekend ETL job failed silently, nobody got notified, and now there's a room full of executives staring at stale numbers. This exact scenario plays out in organizations every week, and it's almost always preventable.
Data reliability isn't glamorous work. Nobody throws a party when the refresh succeeds at 3 AM. But when it fails and nobody notices, the cost — in credibility, in decisions made on bad data, in scrambled Monday mornings — is very real. Power BI's scheduled refresh system is your first line of defense, and its alerting capabilities are the safety net that catches you when something goes wrong. Together, they turn your reports from "probably current" into genuinely trustworthy enterprise assets.
By the end of this lesson, you'll have a complete, working knowledge of how to configure scheduled refresh for a Power BI dataset, set the correct gateway and credential settings, and build a proactive alerting system so that refresh failures are caught immediately — not discovered accidentally by an unhappy stakeholder.
What you'll learn:
Before diving in, you should have:
If your data lives entirely in cloud services like Azure SQL Database, SharePoint Online, or Dynamics 365, you may not need a gateway. We'll clarify this as we go.
Before touching any settings, let's build a clear mental model of what's actually happening during a refresh. This understanding will save you hours of debugging later.
When you build a report in Power BI Desktop, your data is imported into a compressed, in-memory format called a dataset. Think of it like a snapshot photograph of your source data taken at the moment you hit "Refresh" in Desktop. The report visuals read from this snapshot, not directly from your database.
Once you publish that report to the Power BI service (the cloud), the snapshot travels with it. The snapshot is now frozen in time. Your database keeps changing, but your dataset doesn't — unless you tell the service to go take a new photograph.
Scheduled refresh is the mechanism that tells the Power BI service: "Every day at 6 AM, go back to the original data source, pull fresh data, and update the dataset." The service wakes up at the configured time, connects to your source system, executes the Power Query transformations you defined in Desktop, and loads the results into the dataset.
Here's where it gets slightly more complex. When the Power BI service (which runs in Microsoft's cloud) needs to reach a data source that lives inside your corporate network — like an on-premises SQL Server, an Oracle database, or a local file share — it can't do that directly. Your corporate firewall blocks inbound connections from the internet. This is where the On-Premises Data Gateway comes in.
The gateway is a piece of software installed on a machine inside your network. It maintains an outbound connection to the Power BI service (outbound connections are typically allowed through firewalls). When a refresh runs, the Power BI service sends the query request through this tunnel to the gateway, the gateway runs the query against the local database, and the results travel back through the same tunnel. Your data never has to punch a hole through your firewall — the gateway bridges the two worlds.
Important: The gateway machine must be running 24/7. If the server hosting the gateway is powered off or restarting during a scheduled refresh window, the refresh will fail. Many organizations dedicate a small virtual machine specifically for gateway hosting.
Before setting up a schedule, you need to make sure the Power BI service knows how to authenticate to your data source. If you skip this step, your very first scheduled refresh will fail with a credentials error.
After publishing your report, navigate to your workspace in the Power BI service. Find your dataset — it appears as a separate item from the report. Click the three-dot menu (the ellipsis) next to the dataset name and select Settings.
In the dataset settings page, expand the Data source credentials section. You'll see a list of every data source your dataset connects to. Each one will either show "Configured" or have an "Edit credentials" link. Click "Edit credentials" for any unconfigured source.
A dialog will appear asking for authentication method and credentials. The options you'll see depend on the data source type:
Pro tip: Use a dedicated service account for database credentials rather than a personal employee account. When that employee leaves the company and their account is disabled, every dataset using their credentials will fail simultaneously. Service accounts don't have coffee breaks or resignation letters.
Enter the credentials and click Sign in or Save. Once all sources show as configured, you're ready to set up the schedule.
Still on the dataset Settings page, expand the Scheduled refresh section. You'll see a toggle to turn scheduled refresh on. Enable it.
Now configure the schedule. You'll make decisions on three key settings:
Refresh frequency: The first dropdown lets you choose Daily or Weekly. For most enterprise datasets, daily is the minimum. If your source data updates multiple times per day (like a sales pipeline that syncs every four hours), you'll want to add multiple time slots.
Time zone: This is easy to overlook and causes a lot of confusion. Power BI stores refresh times in UTC by default. If your organization is in US Eastern time, a "6 AM" refresh configured without the correct time zone will actually run at 1 AM or 2 AM Eastern (depending on daylight saving time). Always set the time zone to match your local region before adding time slots.
Time slots: Click "Add another time" to add up to eight daily refresh times with a Pro license. Premium allows up to 48 refreshes per day. Add your desired refresh times. A common enterprise pattern is to refresh at 7 AM (so reports are current before the business day starts), at noon (to capture morning transactions), and at 5 PM (for end-of-day reporting).
Let's say you're managing a retail sales dataset that pulls from an on-premises SQL Server data warehouse. The warehouse loads finish at 5:30 AM each morning. Your schedule might look like this:
Once you've configured everything, click Apply. The Power BI service will now attempt a refresh according to this schedule.
Warning: Power BI does not guarantee exact refresh timing. A refresh scheduled for 6:00 AM may start anywhere between 6:00 and 6:15 AM depending on service load. If your downstream processes depend on the refresh completing by a specific time, build a buffer into your schedule.
After your first scheduled refresh runs, you can inspect the results. In the dataset's three-dot menu, select Refresh history. This shows you a table with every refresh attempt, its status (Completed or Failed), how long it took, and a timestamp.
Click on any failed refresh entry and you'll see an error message. These messages are often cryptic, but here are the most common ones and what they actually mean:
"DM_GWPipeline_Gateway_MashupDataAccessError" — The gateway couldn't reach the data source. Check that the gateway service is running and that the database server is accessible from the gateway machine.
"Credentials are not configured" — You forgot to set up credentials for one of your data sources in the Settings page. Go back and configure them.
"Query timeout expired" — Your Power Query transformations are taking longer than the allowed time (usually two hours for Pro, up to five hours for Premium). This usually means you need to optimize your queries — push more transformation logic into the source database with native SQL queries rather than doing heavy work in Power Query.
"Gateway is offline" — The gateway machine is powered off, restarting, or has lost connectivity. Check the gateway server.
Keeping an eye on refresh history manually isn't sustainable for a production system. You need automation. That's what the next two sections are about.
Power BI has a simple, built-in mechanism to notify the dataset owner when a scheduled refresh fails. It's not sophisticated, but it's your first line of defense and takes about thirty seconds to configure.
On the dataset Settings page, scroll down to find the Scheduled refresh section where you already configured your schedule. Look for the option labeled Send refresh failure notifications to — it may appear as a checkbox or toggle depending on your Power BI service version.
By default, it sends failure emails to the dataset owner. You can also add additional email addresses by clicking the relevant option and typing them in. These can be distribution list aliases (like bi-team@yourcompany.com), which is preferable to individual addresses because team membership can change without you having to update Power BI settings.
When a refresh fails, everyone on that notification list receives an email from no-reply@microsoft.com with a subject line like "Refresh failure for [Dataset Name]." The email includes the dataset name, workspace, and a link to the refresh history so the recipient can investigate.
Limitation: The built-in alerting only tells you a refresh failed. It doesn't tell you if a refresh succeeded but returned an unexpectedly low row count (which could indicate a data source problem that didn't throw an error). It also doesn't let you notify external systems like a Slack channel or a ServiceNow ticket. For those scenarios, you need Power Automate.
Power Automate (formerly Microsoft Flow) is Microsoft's workflow automation tool. It integrates natively with Power BI and lets you build custom notifications that go far beyond a simple email.
We'll build a flow that triggers when a Power BI refresh fails, then sends a formatted message to a Microsoft Teams channel so the entire BI team is notified immediately.
Step 1: Create a new flow
Open Power Automate (flow.microsoft.com) and click Create in the left navigation. Choose Automated cloud flow — this means the flow starts automatically based on a trigger event.
Step 2: Configure the trigger
In the trigger search box, type "Power BI" and select the trigger named When a dataset refresh fails. Click Create.
In the trigger configuration, you'll see two dropdowns:
Step 3: Add the Teams notification action
Click the plus button below the trigger to add an action. Search for "Microsoft Teams" and select Post a message in a chat or channel.
Configure it:
For the Message field, you'll compose the alert text. Use the dynamic content panel to insert values from the trigger. A useful message might look like this:
⚠️ REFRESH FAILURE ALERT
Dataset: [Dataset Name - from dynamic content]
Workspace: [Group Name - from dynamic content]
Time: [Trigger timestamp - from dynamic content]
The scheduled refresh has failed. Please check the refresh history
in the Power BI service and investigate immediately.
Action required: Review error in Power BI → [Workspace] →
[Dataset] → Settings → Refresh History
Step 4: Add an email backup
After the Teams notification, add a second action: Send an email (V2) from the Office 365 Outlook connector. Configure it to send to your BI team distribution list with a similar message. This ensures someone gets notified even if they're not monitoring Teams.
Step 5: Save and test
Click Save. To test without waiting for an actual failure, you can temporarily break your dataset credentials (change them to something incorrect), trigger a manual refresh from the dataset Settings page, and watch for the notification. Remember to restore the correct credentials afterward.
Power Automate tip: Give your flow a meaningful name like "PBI Refresh Failure — Sales Dashboard — Notify BI Team." When you eventually have fifteen flows, vague names become a maintenance nightmare.
Let's put this all together with a realistic practice scenario.
Scenario: You're a BI analyst at a regional logistics company. You've built a Power BI report called "Shipment Operations Dashboard" that connects to a SQL Server database on your company's internal network. The database updates every night at 3 AM. Your stakeholders expect fresh data every morning by 8 AM. You need to configure scheduled refresh and ensure you're alerted immediately if anything goes wrong.
Exercise steps:
Open the Power BI service and navigate to your workspace. Find the "Shipment Operations Dashboard" dataset. If you don't have this exact dataset, substitute any published dataset you have available.
Open the dataset Settings page (three-dot menu → Settings). Navigate to Data source credentials and confirm all sources show as configured. If any show "Edit credentials," configure them using SQL Server authentication with a service account (for this exercise, use whatever credentials your environment requires).
Expand the Scheduled refresh section. Enable the toggle. Set the time zone to your local time zone. Add two time slots: 6:00 AM (your pre-work morning refresh) and 12:00 PM (midday update). Click Apply.
In the same section, find the refresh failure notification option and ensure your email and your manager's email are both listed as recipients.
Open Power Automate and create a new automated flow triggered by When a dataset refresh fails. Select your workspace and dataset. Add a Teams notification action posting to a channel your team uses. Add an email action as a secondary notification. Save the flow.
Test your setup: In the dataset Settings page, change one data source credential to an intentionally wrong password. Click Refresh now (the manual refresh button, available in the dataset three-dot menu). Wait two to three minutes, then check your Teams channel and email inbox for the alert. Then go back and fix the credential.
Review the refresh history (three-dot menu → Refresh history) and note the error message for the failed refresh you just triggered.
Mistake: Not accounting for gateway maintenance windows
Organizations often schedule Windows updates or server restarts during early morning hours — the same window when Power BI refreshes are often scheduled. If your gateway server restarts at 3 AM and your refresh is scheduled for 3:15 AM, you'll get a gateway offline error. Coordinate with your infrastructure team to schedule server maintenance outside of refresh windows, or schedule your refreshes with a buffer.
Mistake: Using personal credentials instead of a service account
As mentioned earlier, if you configure data source credentials using your personal Active Directory account and your account is locked, expires, or gets disabled, every dataset using those credentials will fail. Always use a dedicated service account with a non-expiring password (following your organization's security policies).
Mistake: Forgetting that DirectQuery doesn't use scheduled refresh
If your dataset uses DirectQuery mode instead of Import mode, there's no data to refresh — every visual queries the source directly in real time. Scheduled refresh doesn't apply to DirectQuery datasets. If someone asks you "why isn't refresh running?" check whether the dataset is in DirectQuery mode first.
Mistake: Setting refresh frequency higher than your source data actually updates
Refreshing eight times a day when your source data only changes once a night wastes refresh capacity, slows the service for other users, and adds noise to refresh history logs. Match your refresh frequency to how often the source data actually changes.
Troubleshooting tip: Check gateway logs
When refreshes fail with mysterious gateway errors, the gateway software itself maintains logs on the gateway server machine. Navigate to the gateway application on the server, go to Diagnostics, and export the logs. These logs often contain the actual error from the database driver — far more informative than the sanitized error message shown in the Power BI service.
Let's review what you've built in this lesson. You now understand that Power BI datasets hold snapshots of source data, and scheduled refresh is the mechanism that keeps those snapshots current. You know when you need a gateway (on-premises data) and when you don't (cloud sources). You've configured data source credentials correctly, set up a realistic refresh schedule with appropriate time zone settings, and enabled the built-in failure notification email.
More importantly, you've gone beyond the basics by building a Power Automate flow that sends rich, actionable alerts to your team the moment a refresh fails — before your stakeholders discover the problem themselves.
A reliable data refresh pipeline, combined with proactive alerting, is what separates "we have dashboards" from "we have a trustworthy data platform." That's not a small distinction in an enterprise environment.
Where to go next:
Learning Path: Enterprise Power BI