Your Power BI Refresh Failed
and Nobody Noticed

On Friday afternoon someone asks why a figure looks low. You check, and the dataset last refreshed on Tuesday. It has been serving three-day-old numbers to everyone who opened it since, and the dashboard gave no indication whatsoever.

This is the worst class of reporting failure, because a stale dashboard looks identical to a working one. Nothing is broken on screen. People made decisions on it all week.

Why This Is Worse Than a Crash

A report that throws an error gets reported within minutes. A report that silently serves old data can run for weeks, and when it is eventually discovered, the damage is not the stale number — it is that nobody can now say which decisions were made on good data and which were not.

Power BI does email the dataset owner on failure. In practice that address is frequently a person who has changed roles, or the mail is filtered into a folder nobody reads. Relying on the default notification is the single most common reason these go unnoticed.

Cause 1: Expired Credentials

The most common cause by a wide margin. The account used to connect to the source has its password rotated, its token expires, or it is disabled when somebody leaves. The refresh then fails on every subsequent run.

The version that causes real damage is a dataset connected using a named individual's account. When they leave the company, every dataset they ever configured begins failing, and nobody knows how many that is until the reports start disagreeing with reality.

Cause 2: The Gateway

If any source is on-premises, traffic passes through the on-premises data gateway, and it introduces several failure points that have nothing to do with your model.

The gateway machine gets rebooted for patching and the service does not restart. The gateway software passes its support end date. The server runs out of disk during a large refresh, because the gateway spools data locally while it works. Or somebody changes a firewall rule.

What to check, in order

1. Is the gateway service running?
     services.msc -> "On-premises data gateway service"

2. Is the gateway online in the service?
     Power BI Service -> Settings -> Manage connections and gateways

3. Is the gateway version current?
     Microsoft supports roughly the last six monthly releases.
     An out-of-date gateway fails without an obvious message.

4. Disk space on the gateway machine?
     Spooling needs headroom. A full disk fails mid-refresh.

5. Can the gateway machine still reach the source?
     Test the connection from that machine, not from yours.

Point four catches people out repeatedly. The refresh worked for a year and then started failing intermittently as data volume grew past the free space on the gateway machine.

Cause 3: Timeouts

Refreshes have time limits, and a query that has slowly grown past one fails at what looks like a random point.

The signature is intermittency: it succeeds at 6am and fails at 9am, because the source database is under load from other work at 9am. Teams often chase this as a Power BI problem when the cause is contention on the source.

The durable fix is usually incremental refresh — process only what changed rather than reloading history every time. A dataset reloading five years of transactions daily to add one day of new rows is doing hundreds of times more work than necessary, and it will eventually cross a limit.

What incremental refresh changes

Full refresh, every day:
    Load 5 years of sales    ~18,000,000 rows    22 min
    -> grows every day, until one day it does not finish

Incremental, same dataset:
    Refresh last 7 days         ~70,000 rows      40 sec
    Archive partitions older than 7 days: untouched
    -> runtime stays flat as history grows

Cause 4: The Source Changed Shape

Someone renames a column, changes a data type, or drops a field from a view. Power Query references columns by name, so the step referencing it fails and the refresh stops.

This one is nobody's fault in particular. The database team had no reason to know a Power BI dataset depended on that column, because nothing told them. The lesson is less about the fix than about the process: analytical dependencies on operational schemas should be written down somewhere the database team will see.

Where you cannot control the source, defensive Power Query helps. Selecting columns explicitly rather than removing others means a new column does not break anything, and it fails with a clear message when one genuinely disappears.

Cause 5: It Succeeded, and It Is Still Wrong

The most dangerous case, because the refresh reports success.

A source returns an empty result rather than an error — an API returning an empty array, a file present but blank, a view filtered to nothing by an upstream change. The refresh loads zero rows perfectly successfully, and your dashboard shows zero sales for the region, which people read as a business collapse rather than a pipeline fault.

Nothing in the platform catches this. A successful refresh of nothing is a successful refresh. You need your own validation.

A staleness and volume check in the model

Data Freshness Hours =
DATEDIFF( MAX( Sales[OrderDate] ), NOW(), HOUR )

Refresh Health =
VAR Hours = [Data Freshness Hours]
VAR Rows  = COUNTROWS( Sales )
RETURN
SWITCH( TRUE(),
    Rows = 0,     "NO DATA LOADED",
    Hours > 48,   "STALE - " & Hours & "h old",
    Hours > 26,   "CHECK - " & Hours & "h old",
    "OK"
)

// Put this on every report page, top right, small.
// Silent when healthy, obvious when not.

Getting Told Before Your Users Do

• Put a freshness indicator on the report. The cheapest fix on this list. A small timestamp means a user notices staleness in a second rather than after acting on it.
• Route failure notifications to a shared channel, not an individual's inbox. Teams or email to a distribution list, never a named person who might change roles.
• Alert on volume, not only on failure. A row count outside an expected range should page somebody even when the refresh reported success.
• Use a service account with a managed credential for every scheduled refresh, so leavers cannot break your reporting.
• Review refresh history monthly. Intermittent failures show up as a pattern long before they become constant.

Triaging One That Just Failed

When a refresh has failed and you need it working this morning, the order you check things in matters, because the cheap checks eliminate the most common causes.

1. Read the actual error. Refresh history in the dataset settings gives the message, not just the failure. Most people skip straight to guessing.
2. Did it ever work? A refresh that has never succeeded is a configuration problem. One that worked until Tuesday is a credential, gateway or source change — and the Tuesday date usually tells you which.
3. Check credentials next. It is the most common cause and takes thirty seconds to rule out.
4. Then the gateway, if any source is on-premises. Service running, gateway online, version current, disk free.
5. Then test the query in Desktop against the same source. If it fails there too, the problem is the source or the query, not the scheduled refresh.
6. Only then look at timeouts and volume. These are real but rarer, and they usually present as intermittent rather than constant failure.

Working in that order resolves most incidents inside ten minutes. Working in the reverse order, which is what people do when they assume the problem is complicated, can take a morning.

What We Would Do

Every pipeline we build has validation before publication: row counts within expected bounds, freshness checks, and alerting to a shared channel rather than a person. If a check fails, the refresh stops and somebody is told, rather than publishing something that looks fine.

When we take over an existing environment, the first pass is usually an audit of which datasets refresh under a personal account and which have no validation at all. It is unglamorous and it removes an entire category of incident.