Last updated: 2026-07-19
Monitoring Check Configuration Template
A template for standardizing your monitoring check configurations. Define which endpoints to monitor, how often, from where, and what thresholds trigger alerts.
Use this template to standardize how your team configures monitoring checks. Covers endpoint types, check intervals, probe regions, alert thresholds, and alert channel assignments.
Endpoint inventory
Document every endpoint that needs monitoring: production website (https://example.com), API endpoints (/api/v2/health, /api/v2/auth), third-party integrations (payment gateway, email provider), internal services (admin panel, database health check), and scheduled tasks (backup, data sync, invoice generation). Each entry specifies the check type (HTTP, HTTPS, TCP, DNS, SSL, heartbeat), the expected response, and the criticality level.
Check intervals by tier
Critical services (customer-facing, revenue-impacting): 30-second checks from 3+ regions. Important services (internal tools, admin panels): 1-minute checks from 2 regions. Non-critical services (staging, dev environments): 5-minute checks from 1 region. Scheduled tasks: heartbeat window set to 2x the expected interval (e.g., a 1-hour backup job gets a 2-hour heartbeat window).
Alert threshold configuration
Define alert thresholds per endpoint. Critical services: alert on 1st consecutive failure, immediately notify on-call. Important services: alert on 3rd consecutive failure (filters out transient network blips), notify team Slack channel. Non-critical services: alert on 5th consecutive failure, send email summary. Quiet hours: suppress non-critical alerts from 10 PM to 7 AM in the team's timezone.
Alert channel routing
Critical alerts: PagerDuty (on-call rotation), Slack (#incidents channel), email (ops team). Important alerts: Slack (#alerts channel), email (team distribution list). Non-critical alerts: email (daily digest, not real-time). Status page updates: all critical and important incidents auto-update the public status page. Non-critical incidents do not.
- Inventory all endpoints with check type, criticality, and expected response
- Assign check intervals: 30s for critical, 1m for important, 5m for non-critical
- Set alert thresholds: 1st failure for critical, 3rd for important, 5th for non-critical
- Configure quiet hours per monitor to suppress non-critical alerts overnight
- Route alerts to channels: PagerDuty for critical, Slack for important, email for non-critical
- Set up heartbeat monitors for all scheduled tasks
- Add SSL monitors for all HTTPS endpoints
- Enable auto-incident creation for all critical and important monitors
Frequently asked questions
How many check intervals do I need?
Three tiers cover most teams: 30 seconds for critical, 1 minute for important, 5 minutes for non-critical. More tiers add complexity without much benefit. Start with these three, add more only after you have been running monitoring for a month and find a genuine need for finer granularity.
Should I monitor staging environments?
Yes, but at lower priority. Staging monitoring helps catch issues before they reach production. Use 5-minute checks with delayed alerts (3 consecutive failures). Route staging alerts to a dev channel, not the on-call rotation. Do not put staging monitors on your public status page.
What is the "right" alert threshold?
For production services, alert on the 1st failure but verify with a second probe before notifying. PingWatchdog confirms failures from multiple regions to avoid false alarms. For less critical services, alerting on the 3rd consecutive failure filters out transient issues without missing real outages. Start conservative (3 failures for everything) and tighten thresholds for services where speed matters more than noise reduction.