A weekly maintenance review should leave the next operator able to answer four questions: what was checked, what changed, who considered it, and what still needs evidence. You can use this routine with a spreadsheet, your existing ticket system, or a monitoring product.
The checklist below is a proposed operating method, not a report of measured customer results. Adapt the cadence to your actual service agreement and response capacity.
Prepare a reviewable site list
Start with authorized sites and representative URLs. Record the client or internal owner, page purpose, scan profile, and last reliable observation. Confirm the monitoring scope matches what you have agreed to maintain.
Do not activate old client entries just because they remain in a tool. Check current authorization and ownership. Likewise, keep payment, portal, and other private workflows outside a public-page scan unless a separate appropriate test has been scoped.
First pass: freshness and failed attempts
Before sorting by grade, look for sites without a usable baseline and sites whose latest check failed. Put these in a measurement queue, with the most important visitor journeys reviewed first.
For each, record:
- The last reliable evidence and its timestamp.
- The latest attempt and the specific error or missing category.
- Whether there is any separate evidence of a visitor-facing problem.
- Who will investigate and the next bounded action.
A timeout does not establish recovery, and it does not establish that all visitors experienced an outage. Keep the two questions separate.
Second pass: changes that deserve attention
Open the changed finding, then compare the same URL and check scope. Confirm that a profile change or missing category did not merely alter the score calculation.
For a performance regression, preserve the measurement conditions. web.dev's explanation of lab and field differences is a useful reference when a current lab result and aggregated visitor data appear to disagree.
Choose one of three human decisions: investigate further, assign a repair, or accept the intentional change with a reason. Record the decision in the team's existing work system so the next person can follow it.
Record review without claiming repair
A reviewed finding means attention was given to that observation. It can still require work. Use a note like this fictional example:
Reviewed the changed canonical on the services page. The new destination does not match the planned URL. Assigned to the developer to inspect the template. The finding remains open pending a comparable recheck after correction.
The note gives the next operator enough context without implying that someone has already fixed the page.
Recheck the correction
After the repair is published, check the same URL and relevant profile. Read the fresh evidence for the original finding. If the check completes and supports the correction, record the observation that verified it.
If the recheck is incomplete, keep the unresolved finding and last reliable evidence visible. Do not substitute “a new scan ran” for “the repair was measured.” If a separate browser task was tested, record that result separately too.
Finish with a compact handoff
Use this copyable review record:
Review period and operator:
Authorized sites and URLs covered:
Latest usable evidence:
New or changed findings:
Reviewed decisions and reasons:
Repairs assigned in the existing work system:
Verified corrections and supporting observations:
Incomplete checks and next actions:
Checks or workflows outside this review:
A quiet week can still be useful: record that fresh evidence was inspected and whether action was needed. Do not invent a resolved issue just to make the report look busy.
See the fictional Portfolio walkthrough for the same four states in PageVital, or use the maintenance report template to turn your record into a client-facing summary. The Portfolio plan adds recurring organization across sites; the free scan is a single snapshot.