At twenty client sites, a spreadsheet and a shared inbox can feel adequate. At two hundred, small inconsistencies multiply: monitors have unclear names, former clients remain active, alerts reach the wrong technician, and nobody knows whether an exception is temporary or permanent.
The remedy is an operating model that treats each monitor as part of a client service, not as an isolated technical object.
Start with a service inventory
Use one stable identifier for each client and each protected service. Record the live hostname, environment, commercial owner, technical owner, service tier, important journeys, maintenance window and escalation route. Keep monitoring names derived from that inventory so alerts can be reconciled without guesswork.
- Every hostname belongs to a current client and contract.
- Every check names the service, environment and check type.
- Every alert route has a current owner and fallback.
- Every exception records a reason and review date.
Define service tiers before intervals
Not every client site needs the same monitoring depth. Define service tiers from the promised response, business impact and protected journeys. A brochure site may need DNS, TLS and HTTP content checks. A commerce site may also justify checkout, payment hand-off and background-order checks.
| Tier | Possible coverage | Response posture |
|---|---|---|
| Foundation | DNS, TLS expiry, homepage HTTP and content marker | Business-hours triage unless the contract says otherwise |
| Business-critical | Foundation plus important forms, login or API endpoints | Faster confirmation and named escalation |
| Transaction-critical | Business-critical plus browser journey and background-job heartbeats | Explicit on-call and client communication process |
These are planning examples, not service-level recommendations. The client agreement and real operating capacity should determine the final scope.
Route by ownership and service, not by tool
A monitoring platform is only one source of operational events. Route alerts according to who can act. Certificate renewal may belong to hosting operations, a failed form to the web team, and a missed backup heartbeat to the maintenance owner. A generic monitoring inbox can remain an archive, but it should not be the sole response mechanism for urgent services.
When a client requires direct notifications, agree what they will receive. Raw probe failures can create unnecessary concern. A confirmed incident update with an owner and next review time is usually more useful.
Control alert noise deliberately
Track noisy monitors as defects. Common causes include unstable third-party dependencies, an overly strict response-time threshold, content markers that change during routine publishing, and browser journeys with fragile selectors.
Count alerts that required action, alerts closed as false or unactionable, and incidents first reported by somebody outside monitoring. The pattern is more useful than a single uptime percentage.
Use maintenance windows, confirmation rules and severity routing to reduce noise, but do not suppress a check indefinitely. Every suppression should have an owner and expiry.
Run a monthly monitoring review
Reconcile the monitoring inventory with active clients and current services. Remove former properties only after contractual and retention requirements are checked. Add newly launched sites, certificates, scheduled jobs and critical journeys. Review contact routes and test one non-production notification path where safe.
Also review the misses. If a client reported a failure that monitoring did not detect, identify the missing question rather than simply reducing every interval.
Starter operating model for 20 to 200 sites
- One inventory with a stable client and service identifier.
- Three monitoring tiers tied to contractual response, not sales labels.
- Named technical owner and backup route for each critical service.
- Confirmation before client-facing escalation.
- Monthly noise, coverage and stale-monitor review.
- Quarterly safe recovery and communication exercise.
Primary references
- Google SRE: Monitoring Distributed Systems, on actionable alerts and avoiding noise.
- Google SRE: Managing Incidents, on clear roles and structured incident response.