Power BI data refresh: planning freshness and troubleshooting failures

Define freshness in business terms

Begin with the reporting decision. A Monday planning meeting may need complete activity through Sunday; an operations queue may need a much shorter delay. Record the source cutoff, expected processing time, timezone, and latest acceptable availability.

Use an illustrative sequence: the source export is complete by 6:00 a.m., preparation finishes by 6:30, and the validated report is available by 7:00. A refresh started at 5:45 may succeed while missing the intended batch. These times are planning examples, not service guarantees.

Understand which dependency needs refreshing

In Import mode, refresh loads source data into the model. DirectQuery generally queries the source instead of importing most data, but it does not remove every freshness or operational dependency. Microsoft documents the differences in its data refresh guidance.

When a source is not directly reachable from the service, an appropriate gateway may be required. Record where it runs, who administers it, how the connection is managed, and which reports depend on it. Verify current licensing and capacity limits in Microsoft's documentation instead of choosing a schedule from an old screenshot.

Troubleshoot from the source toward the report

1. Confirm source readiness. Is the expected batch present, complete, and accessible to the approved identity?
2. Read refresh history. Capture the failure message, timing, and affected model before changing configuration.
3. Check connections. Verify gateway availability where applicable and review credential or permission changes.
4. Check transformations. Look for renamed columns, changed types, unexpected files, or new values that break a rule.
5. Validate the result. Reconcile the expected period and source totals before declaring recovery.

Microsoft's scheduled refresh guidance identifies history, gateway status, and credentials as starting points. Repeated failures can disable a schedule, so confirm it is active after resolving the underlying problem.

Keep operational success separate from validity

Store three indicators: the source's latest business timestamp, the last successful processing timestamp, and the latest reporting period that passed validation. A report can surface these without exposing credentials or technical logs to its audience.

Add checks tied to consequences. Did the record count unexpectedly fall? Are key fields missing? Did today's feed contain one location when five were expected? A successful job is a necessary observation, not a substitute for those questions.

Write a recovery runbook before it is needed

Identify the incident owner, escalation contact, relevant logs, safe recovery steps, and evidence required to reopen the report. Explain what viewers should do while information is stale. Avoid treating a re-run as a verified fix.

Test a recoverable outage in a nonproduction environment and confirm that the alert is actionable. AVIZ DATA can scope reporting and workflow support around this requirement. The companion data quality guide distinguishes a healthy pipeline from a trustworthy result.