A failed scheduled refresh is the quietest way to lose trust in BI: the report still opens, the numbers are just yesterday’s — or last week’s. By the time someone notices, the owner has usually been ignoring failure e-mails for days. This guide lists the failure causes we see most, how to confirm each one, and what monitoring should look like beyond a single dataset.
Where the evidence lives
Each semantic model keeps a refresh history (model settings → Refresh history, or the Get Refresh History REST API) with per-attempt status, duration and the error payload. Failure notifications go to the model owner only — which is exactly why tenant-wide failures go unnoticed.
The usual suspects
- Expired or broken credentials. OAuth tokens lapse, service-account passwords rotate, people leave. The error mentions credentials, authentication or AAD. Fix by re-entering credentials on the data source — and prefer service principals over personal accounts wherever the source supports them.
- Gateway problems. For on-premises sources: gateway offline, outdated, or missing the data source definition. Check the gateway cluster’s status page and update cadence; a single-node gateway is a single point of refresh failure.
- Timeouts. Refreshes are capped at roughly 2 hours on shared and 5 hours on Premium/Fabric capacity. Models that creep toward the ceiling need incremental refresh, query folding checks, or fewer high-cardinality columns.
- Memory and capacity pressure. On dedicated capacities a refresh can be evicted when concurrent refreshes and interactive load exceed the SKU’s memory. Symptoms: intermittent failures clustered at busy hours. Spread schedules or right-size the capacity.
- Schedule pile-ups and limits. Shared capacity allows 8 scheduled refreshes per model per day, Premium/Fabric 48 — and dozens of models refreshing at 08:00 sharp compete for the same compute whether or not any single one hits its limit.
Monitoring beyond one dataset
Checking refresh history model-by-model does not scale past a handful of workspaces. Healthy tenants track, in one place: success rate over time, the models failing most often, when each last failed, and the failure cause class — because ten "credential expired" failures are one problem, not ten. PGR Sonar’s Refresh Health page does exactly this across the tenant, and on eligible plans an AI diagnosis groups each morning’s failures by likely cause with a concrete fix — so you wake up to a short list instead of a wall of red.