Estimated reading time : 4 min · Published
Check key journeys each month
Open the main pages on mobile and desktop. Test navigation, filters and the contact form with a controlled enquiry; confirm delivery and visible feedback.
Inspect main images, cards, internal links and downloads. An empty listing can go unnoticed when nobody visits like a new customer.
Monthly checks do not replace testing after a recovery-related change. New storage, key rotation, a CMS migration or a change of owner can invalidate a previously usable procedure. Choose a targeted test in isolation for each event. Record the procedure version and the actual backup references tested instead of carrying forward a previous pass automatically.
Separate evidence of archive retrieval, readability or decryption, consistent data and a working journey. A hash may check correspondence with an expected reference; it does not prove that CMS, database and media work together. Also time retrieval and access to authorised recovery resources. Record results and missing elements without putting keys or passwords in a public report.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Event | Proposed targeted test | Evidence to keep |
|---|---|---|
| Storage change | Retrieve the complete set from the authorised recovery context | Backup references, access and retrieval time |
| Backup key rotation | Decrypt a retained generation through authorised means | Generation and result without publishing the key |
| CMS or database migration | Restore consistent code, database and media in isolation | Versions, recovered items and journey tested |
| Change of owner | Have the authorised substitute follow the procedure | Missing steps, required access and corrected procedure |
Keep content accurate
Assign an owner to changing facts such as prices, hours, availability, service areas and terms. Update related pages together to prevent contradictions.
Review articles when a tool or recommendation changes. Change the public modified date only when an actual editorial update warrants it.
Plan for continuity
Document backup frequency and test restoration. Schedule component updates and check essential functions after each change.
Review page errors, enquiries and available search data. Record what changed and the outcome before choosing pages to improve, combine or retire.
In this fictional maintenance exercise, four checks each have a criterion: one passes, one fails and two remain unverified. An unknown result must not default to green. The homepage can respond correctly while the form saves nothing; similarly, a provider accepting a message or a backup job finishing does not establish the whole expected journey.
For each gap, record an owner, authorized deputy and next verifiable action. The table's roles are examples rather than a client's declared organization. Keep the date, environment and test reference without copying private messages. Four checks cannot establish monthly availability; that requires a defined period, scope and measurement method.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Check | Result and limitation | Owner and expected next action |
|---|---|---|
| Homepage | Passed: status 200 and expected content observed | Web role: retain this homepage-only result |
| Form | Failed: response 200 but no enquiry saved in the test | Application role: investigate the gap and rerun the journey |
| Confirmation email | Unverified: provider accepted, test receipt not checked | Email role: verify the route to the test recipient |
| Backup | Unverified: job finished, restoration not tested | Backup role: perform the planned isolated rehearsal |
- Google SRE : Monitoring Distributed Systems
Google SRE, consulted 22 October 2026: internal signals and user-visible behaviour. The four checks and results are fictional.
Monitoring that leads to action
Separate regular checks, incident handling and editorial changes. Define an alert state, owner and action for each check. An unowned list does not ensure continuity.
Record changes and test the affected journey. Review scope and recovery when changing a dependency or supplier. Opening hours, seasonal copy and forms require monitoring alongside technical updates.
Decide in a concrete situation
Fictional example: a team chooses between a carousel redesign and an outdated login component. Consider exposure, affected users and alternatives; the most visible change is not necessarily the most useful.
Record component, version, reason, owner and post-change check. Separate presentation tasks from access or security fixes; a backup alone does not validate an update.
- Automate and verify TLS certificate renewal
Understand TLS deadlines for 2026–2029, test renewal, inspect the certificate actually served and prepare alerts.
An alert needs an owner and an action
Specify what an automated check observes: page response, certificate expiry, backup execution or message delivery. A 200 response may still contain an error page. Include at least one critical-journey check and identify who investigates its alert.
Reference documents
Content updated on