Refresh Reliability is an ops program. In the first 90 days after a major release, classify every Failed row in refresh history; do not treat “try again” as a fix.
Days 1–30: make failure visible
- Assign a dataset steward (name + backup) on every certified semantic model in the workspace description.
- Turn on failure notifications (email/Teams) for consecutive failures — Power BI service refresh settings, not a manual glance at History.
- Export refresh history weekly; tag each failure: GatewayNotReachable, Credential, Query/timeout, Capacity throttling.
Days 31–60: kill fragile paths
Delete Personal gateway bindings on organizational facts. Replace Excel-on-sharepoint-as-system-of-record with SQL/warehouse extracts. In Power Query, verify View Native Query exists for filter steps — if grayed out, you are downloading full tables then filtering in mashup, which blows the night window. On Premium/Fabric capacities, introduce incremental refresh only when a reliable RangeStart/RangeEnd folding column exists.
Days 61–90: prove recovery
Run two drills: (1) stop the On-premises data gateway service on one cluster node during a non-critical slot; (2) rotate the SQL service account password and update Manage gateways → data source credentials before the next schedule. Record mean time to restore. If Import refreshes are stable inside the SLA but DirectQuery dashboards spike CPU at 09:00, document that tradeoff — do not “fix DirectQuery” as a reliability win for board packs.