An automated report needs more than a refresh schedule. It needs a maintenance schedule that assigns checks to the right interval and names the person who responds when something fails. The cadence below is a practical template, not a vendor requirement; adjust it to the report's business impact and data frequency.
Every run: verify freshness and basic integrity
For each scheduled run, capture whether the refresh completed, when it started, how long it took, and what error appeared if it failed. Microsoft says Power BI refresh history exposes status, start time, duration, and error details. Also check that the newest expected date or transaction period is present, the audience received the report, and one or two control totals reconcile to a trusted source. See Microsoft's scheduled refresh guidance.
Automate these checks where practical, but keep the alert understandable: identify the report, failed stage, last successful run, owner, and next action. A green delivery message without a freshness or reconciliation check can hide a report that rendered correctly from stale data.
Weekly: review patterns, not just incidents
Once a week, review refresh history for repeated slowdowns, intermittent failures, or warnings. Microsoft recommends periodic review of refresh history and notes that warnings can point to broken measures, data-type mismatches, or an outdated gateway. Confirm that credentials and gateways are healthy, failure notifications still reach an active owner, and new source columns have not changed key measures. See Microsoft's data refresh guidance.
If the report runs only monthly, perform this pattern review after each run instead of inventing weekly work. Frequency should follow risk and actual activity.
Monthly: inspect ownership, access, and definitions
Each month, confirm a named primary owner and backup. Review recipients and edit permissions, remove stale access, and check whether source owners announced schema or policy changes. Revisit the definition of the most important metrics: numerator, denominator, exclusions, time zone, and late-arriving data treatment. Record changes in a small maintenance log with date, owner, reason, and validation result.
For a low-impact personal report, this can be quarterly. For payroll, finance, compliance, safety, or customer commitments, use a cadence approved by the accountable owner and the relevant rules.
Quarterly: test recovery and usefulness
Run a controlled failure drill or at least rehearse the recovery steps. Confirm that someone other than the primary owner can locate credentials through the approved secret-management process, find the source list, interpret the alert, and rerun or restore the report without guessing. Do not place passwords in the maintenance document.
Then ask whether the report still changes a decision. Identify active users, the decision they make, the acceptable delay, and any duplicate report that now serves the same purpose. A report that is technically healthy but unused is still a retirement candidate.
Annually or after major change: reassess the design
After a source migration, organizational change, new regulatory requirement, or major dashboard redesign, repeat the ownership, access, metric, and reconciliation review immediately rather than waiting for the calendar. At least annually, decide whether to keep, redesign, replace, or retire the automation. Archive the decision and evidence.
A sustainable schedule is short enough to perform and strong enough to catch silent failure. Start with every-run freshness checks, periodic history review, monthly ownership and definition checks, quarterly recovery and usefulness reviews, and event-driven reviews after major changes. Assign every task to a role, set an escalation path, and keep proof that the checks happened.
Sources
- Configure scheduled refresh — Microsoft Learn
- Data refresh in Power BI — Microsoft Learn