An automated report should be troubleshot as a chain: source data, credentials, gateway or connector, transformation, schedule, and final delivery. Start with the first bad run, then use a change log to compare it with the last good run. This is faster and safer than changing several settings at once because every test has a recorded reason and result.
Capture the failure before changing anything
Record the report name, owner, expected run time, actual status, error text, affected audience, and a link or identifier for the failed run. Save a copy of the last known-good output and the current bad output. If the platform exposes refresh history, export it before retrying. Microsoft documents that Power BI refresh history and exported CSV details can include outcomes, duration, error messages, error codes, and owners; the schedule view can also reveal overlapping runs and resource contention (Power BI refresh summaries).
The first check is whether the report is stale, incomplete, empty, or genuinely wrong. Those symptoms point to different parts of the chain. A stale visual can exist even after source data changed, while a failed data refresh may leave the previous successful data visible. Note the exact timestamp and row or total that proves the problem.
Build a narrow change log
Create one row for each relevant change between the last good run and the first bad run. Include the time, person or system, component, old value, new value, reason, and rollback method. Check source table or column changes, file replacements, credentials, permissions, connector or gateway updates, transformation logic, filters, time zones, schedules, and delivery destinations.
Schema changes deserve special attention. Microsoft explains that renamed or removed source columns or tables can cause Power BI service refreshes to fail, and that correcting the mismatch may require a schema refresh in Power BI Desktop followed by republishing (Power BI data refresh). Treat that as an example of a general rule: compare the data contract expected by the report with the contract the source now supplies.
Test one boundary at a time
Begin at the source. Confirm that the expected record exists, its timestamp is current, and the service account can read it. Then test the connector or gateway, the transformation, the dataset or semantic model, the visual, and the delivery channel in order. Make one reversible change, run one controlled test, and add the outcome to the log. Do not edit production logic merely to make an error disappear.
If the failure is intermittent, compare run duration and schedule overlap. A job that used to finish before the next one started may now collide with another refresh. Move a test run to a quiet window only when the change log records the original schedule and the intended rollback.
Prove the repair
A green status is not enough. Reconcile at least one source value, one aggregate, and the report's freshness timestamp. Confirm that the intended recipients can open the result and that the next scheduled run also succeeds without a manual intervention. Close the change-log entry with the root cause, the exact fix, evidence links, owner, and a review date. If the cause remains uncertain, label the result as a workaround and keep monitoring rather than claiming a permanent repair.
Sources
- Refresh summaries for Power BI — Microsoft Learn
- Data refresh in Power BI — Microsoft Learn