Website performance monitoring needs an owner and a response routine. A stream of scores does not tell a team which change to investigate, who is working on it, or whether the correction was verified.
Build the routine around four records: a baseline, a new observation, a review decision, and recovery evidence.
Define the scope before scheduling
Choose the authorized URLs and the jobs they serve. Record the profile or device conditions used for each. Keep a small representative set you can actually review; add coverage when a different template or critical journey requires it.
Separate these monitoring jobs in your plan:
- Availability: can a service be reached from the monitoring location?
- Performance: what does the selected measurement show about loading or interaction?
- Configuration: did a header, tag, or other observed signal change?
- Transaction testing: can a defined visitor workflow complete?
One does not establish the others. PageVital's public checks do not prove that a form was delivered, a purchase settled, or every visitor can reach the service.
Establish usable baseline evidence
Save a successful measurement before treating later results as a trend. Include its timestamp and coverage. If a measurement is unavailable, keep that gap visible instead of filling it with an assumed pass.
For performance, confirm whether you are comparing lab observations or field data. Google's guidance on lab and field differences explains why their conditions and coverage can produce different results. They are complementary investigation tools, not interchangeable samples.
Choose a cadence you can support
A practical starting proposal for a small agency is one scheduled weekly review plus a check after a material release. This is a workflow suggestion, not a universal frequency recommendation or an uptime commitment.
Choose a tighter routine when the consequences justify it and the team can respond. Record the actual coverage and delivery settings in the tool you use. Never assume “monitoring enabled” means an email, text, or escalation path has been configured and tested.
Review the change, then assign the action
Use a decision record like this:
Finding and affected URL:
Last reliable observation:
Latest attempt and its outcome:
What changed:
Reviewer and decision:
Repair owner, if needed:
Evidence required to close:
“Reviewed” means a person considered the finding. It should not mean “fixed.” The reviewer may decide to investigate, accept an intentional change, or hand off a repair.
Verify recovery without erasing uncertainty
After a repair, run a fresh comparable check. Confirm the specific issue changed as intended. If the recheck fails, retain the open finding and the last reliable evidence. A failed attempt cannot prove recovery.
If the scope changes, record that explicitly. Removing the affected page from monitoring is not the same outcome as correcting it.
The Portfolio walkthrough uses fictional data to make these states visible: regression, reviewed, incomplete recheck, and verified recovery. Portfolio monitoring is the paid recurring workflow; a free scan remains a point-in-time snapshot.
Report outcomes a client can understand
A maintenance summary should say what was checked, what changed, what remains open, and what is outside scope. Use the maintenance report template to turn the record into a concise explanation without making an all-clear claim.