The customer asks for a monthly one-page picture of the backup estate - capacity, health, and reduction - instead of a human screenshotting graphs on demand. What should the monitoring configuration provide?
Select an answer to reveal the explanation.
Short Explanation
A report that depends on someone remembering is a report you'll miss one month. Put the summary inside the monitoring layer so it builds itself, stamps itself, and arrives - even in the busiest month of the year. One regular page beats five improvised slide decks.
Full Explanation
Standing operational reporting is a configuration object, not a favor: monitoring platforms that hold capacity, health, and reduction data can generate periodic summaries, and the post-deployment job is to set cadence, scope, and named recipients so the artifact is produced by the system on schedule. The fixed cadence is what gives management a baseline-to-current comparison every month without anyone championing it, and generating the report from the same data as the dashboards keeps its numbers honest. A manual screenshot runbook reproduces exactly the failure the customer wants eliminated - skipped months, drifting formats, no provenance - and it silently depends on the busiest person's calendar. Self-service dashboards serve the people who already look; the monthly one-pager is a push deliverable precisely so readers who never log in still see the trend. An inbox full of every possible alert is an event stream, not a summary: events carry no rollup, no trend context, and no period boundaries, so a month of noise is the opposite of the one page that was requested. Exam caveat: align report scope with its audience - a fleet-level one-pager and per-system drill-downs serve different readers - and verify the first few outputs against source data before hand-off. Operational check: confirm the next scheduled report arrives on time, carries the correct period stamp, reaches the agreed recipients, and matches the dashboard figures.