---
title: Client Website Monitoring Policy Template for Agencies
description: A practical website monitoring policy for agencies — scope, critical journeys, confirmation, alert routing, maintenance windows, ownership, and review.
source: https://pingvera.com/blog/client-website-monitoring-policy.html
---
# Client Website Monitoring Policy Template for Agencies

A website monitoring policy defines what the agency checks, how failure is confirmed, who receives an alert, when the client is informed, and what evidence is required before the incident is closed. It prevents two opposite failures: discovering outages through clients and overwhelming engineers with unactionable alerts.

The policy should monitor business outcomes in layers. Homepage uptime is useful, but it cannot prove that a lead arrived, checkout completed, a scheduled import ran, or the application is safe to use.

## At a glance

For every client website, document:

1. service criticality and support hours;
2. canonical URLs and important audience regions;
3. critical user journeys and success conditions;
4. external, application, integration, and business checks;
5. frequency, timeout, retries, and confirmation logic;
6. maintenance windows and expected exceptions;
7. severity and responsible responder;
8. primary and fallback notification channels;
9. client communication triggers;
10. recovery validation and closure rules;
11. policy owner and review schedule.

## Four layers of website monitoring

### Layer 1: reachability

- DNS resolves correctly;
- TCP/TLS connection succeeds;
- the expected host and path answer;
- redirects end at the canonical URL;
- the response contains an expected marker;
- response timing stays within the service's agreed threshold.

### Layer 2: platform health

- application health endpoint;
- database, cache, queue, and storage status where available;
- scheduled-job heartbeat;
- CMS core/plugin health;
- error-rate or saturation signal;
- backup completion and age.

### Layer 3: integrations

- transactional email delivery;
- CRM/ERP/PIM/OMS freshness;
- payment, tax, shipping, identity, or search-provider availability;
- webhook backlog and dead-letter queue;
- reconciliation result, not only webhook receipt.

### Layer 4: business outcomes

- lead form accepted and delivered;
- order can reach a safe test milestone;
- booking slot can be selected and confirmed;
- user can sign in or recover access;
- important content is visible and indexable;
- catalogue price and stock are acceptably fresh.

## Build the monitoring matrix

Thresholds are examples. Set them from business tolerance and observed behaviour, not copied defaults.

## Write success conditions before alerts

“Check the contact form” is not testable enough. A good success condition includes input, action, observable result, and maximum delay.

Given a synthetic visitor on /contact,
when the visitor submits a uniquely marked test enquiry,
then the website displays the expected success state,
the message appears in the agreed mailbox within 180 seconds,
and the test record is removed or labelled automatically.

Where inbox access is not permitted, agree on a less complete signal and state the limitation. A `200` response proves only that the endpoint answered.

## Confirmation and anti-noise rules

Use confirmation deliberately:

- require consecutive failures for non-critical transient checks;
- confirm from another region or network when regional impact matters;
- do not delay declaration when a high-confidence business journey fails;
- group dependent failures under one incident;
- suppress known maintenance only for the affected checks and time window;
- preserve raw timestamps and results even when notifications are suppressed;
- send recovery only after the same success condition is met consistently.

The objective is not fewer alerts at any cost. It is fewer alerts that do not lead to a decision.

## Alert routing policy

Do not use Slack or Microsoft Teams as the only route for a P1 unless the team has verified after-hours delivery and a fallback outside that platform.

## Maintenance windows

A maintenance window must include:

- affected website and checks;
- start and end in UTC plus local display;
- change owner and rollback owner;
- expected symptoms;
- checks that must remain active;
- client notice reference;
- automatic expiry of suppression;
- post-change validation.

Never disable the whole portfolio because one plugin update is planned.

## Copyable monitoring policy

# Website monitoring policy

Owner: [role]
Version: [number]
Effective: [UTC date]
Review cadence: [quarterly / after material change]

## Scope
Websites and environments: [list or inventory reference]
Service hours: [24/7 or schedule with time zone]
Excluded systems: [explicit list]

## Criticality
Project classes: [A/B/C or equivalent]
Severity model: [P1-P4 policy link]

## Required checks
- Canonical URL and critical pages: [standard]
- Business journeys: [per-site map]
- TLS/domain/DNS: [standard]
- Scheduled jobs/integrations: [standard]
- Backup age: [standard]

## Confirmation
- Failure count: [rule]
- Regional confirmation: [rule]
- Business-path exception: [rule]
- Recovery confirmation: [rule]

## Notifications
- P1: [primary + fallback]
- P2: [primary + fallback]
- P3/P4: [ticket/digest]
- Client communication owner: [role]

## Planned maintenance
Notice period: [value]
Suppression approval: [role]
Maximum suppression: [value]
Post-change validation: [checklist]

## Evidence and retention
Event timestamps: [UTC]
Result retention: [value]
Incident link: [system]
Sensitive-data rules: [policy link]

## Review triggers
- New critical journey
- Hosting, DNS, CDN, CMS, or integration change
- Material incident or missed detection
- SLA change
- Client ownership change

Example: an agency with 40 client sites
The agency originally pings 40 homepages every minute and sends all failures to one Slack channel. Engineers mute the channel after intermittent hosting errors. A client's lead form later stops delivering mail for nine days without an alert.

The revised policy groups sites into three criticality classes, moves actionable events into the help desk, keeps paging for P1/P2, and adds end-to-end form checks for 12 lead-generation sites. The agency has more checks but fewer messages, because every notification has an owner and decision path.

## Common mistakes

- using one policy for a brochure site and a revenue-critical store;
- defining checks without measurable success criteria;
- paging on the first network timeout for every site;
- suppressing checks without automatic expiry;
- closing an incident as soon as the homepage returns;
- storing synthetic customer data indefinitely;
- routing P1 through a single collaboration platform;
- failing to revise the policy after a missed detection.

## FAQ

### How often should an agency monitor a website?

Frequency should reflect the maximum acceptable detection delay. A critical revenue path may justify one-minute checks; a domain-expiry check may run daily.

### Should monitoring run from several regions?

Use regions that represent the audience or help distinguish origin failure from regional network failure. More regions are not automatically better if nobody interprets the differences.

### Is synthetic form submission safe?

It can be, with agreed test data, rate limits, cleanup, privacy controls, and protection against triggering real sales or support workflows. Confirm the client's policy first.

### What is the minimum useful monitoring set?

For most maintained sites: canonical URL, one critical page, TLS/domain, the main conversion journey, and at least one recovery or scheduled-job signal.

## Sources and further reading

- [Google SRE: Managing Incidents](https://sre.google/sre-book/managing-incidents/)
- [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)
- [Pingvera: why a working page does not prove lead delivery](https://pingvera.ru/blog/ne-prihodyat-zayavki-s-sayta.html)

Reviewed: **8 August 2026**.

Next: [Website outage incident response playbook](03-website-outage-incident-response-playbook.md) and [critical user journey monitoring](07-critical-user-journey-monitoring.md).

Pingvera can automate the external checks in this policy, including forms and delivery to a mailbox. Keep ownership, severity, communication, and recovery decisions in the agency's operating model.