When refresh history shows Status = Failed around 08:00, open the detail row. You will usually see messages like “Couldn't connect to the data gateway,” “Credential is missing or invalid,” or “GatewayNotReachable” — not a Power BI service outage. Treat that as an ops ticket on the On-premises Data Gateway, not a redesign of the report.
1. Personal gateway still binding the dataset
In Manage gateways, if the data source shows Personal (cloud), the author’s laptop is the dependency. Laptops sleep, VPN drops, and Windows Update reboots kill the schedule. Move organizational datasets to On-premises Data Gateway (standard) on a dedicated Windows Server VM under an Entra (Azure AD) security group — not the author’s UPN. Credentials should be a gMSA or service account with password rotation in your vault, never the installer’s mailbox password pasted into the gateway UI.
2. Recovery key only on one USB stick
On first install the wizard forces a recovery key. If that key lives only in the consultant’s Downloads folder, any node rebuild requires re-creating data sources and rebinding every dataset. Store the key in Secret Manager / Key Vault the day you create the cluster; test retrieval with a second admin who was not the installer.
3. “Cluster” that has never failed over
Two nodes registered under the same gateway cluster name only help if you have taken node A offline during a non-critical refresh and watched Status = Completed on the dataset. Also confirm the Windows service “On-premises data gateway service” is Automatic (Delayed Start), and that outbound HTTPS to *.powerbi.com and the Azure Relay endpoints used by your region is allowed — folding will look fine in Desktop and fail on the gateway when TCP 443 is blocked.
- Register SQL and file sources once per cluster cluster name, not once per report author.
- After credential rotation, re-test with “Test connection” in Manage gateways before the next scheduled refresh.
- Alert when consecutive failures ≥ 2 so the board pack is not the first alert.