There are two ways to find out your service is degraded: a user tells you, or your monitoring does. Reactive monitoring means your alerting system eventually catches the problem — after it has already affected users. Proactive monitoring means your system detects early warning signals and alerts you before failure is user-visible.
This distinction sounds subtle. In practice it's the difference between a 2-minute detection window and a 20-minute incident that shows up in your status page history.
Reactive Monitoring: Alert After Failure
Reactive monitoring is the baseline. Your monitors check whether endpoints return successful responses. When a check fails, an alert fires. You investigate, identify the cause, and resolve the issue.
This is better than no monitoring. Without it, you rely entirely on user reports — which means detection times measured in minutes or hours, depending on your traffic volume and the time of day the failure occurs.
But reactive monitoring has a structural ceiling. It detects failures that have already happened. The alert fires when a user's request would have failed. Recovery starts only after failure is confirmed. And in most implementations, reactive monitoring only catches hard failures: complete outage, 5xx responses, connection refused. Slow degradation — a service that's technically "up" but performing at 10% of normal speed — often goes undetected until it tips into full failure.
Proactive Monitoring: Detect Before Users Notice
Proactive monitoring adds signals that precede failure. Instead of waiting for an endpoint to return an error, it watches for conditions that reliably predict errors before they occur.
Common proactive signals:
Response time trend. If an API that normally responds in 80ms starts responding in 400ms, something has changed — a slow query, a memory leak, a backing service slowing down. The service is still "up," but it's heading toward failure. A proactive alert fires on the trend, not on the eventual outage.
Threshold degradation. Setting response time thresholds below outright failure (e.g., alert when response time exceeds 500ms, not just when requests time out entirely) catches performance degradation early. You investigate a slow service before it becomes a down service.
SSL certificate expiry. Certificate expiry is entirely predictable. An SSL monitor that alerts 30 days before expiry gives you a month to renew; one that alerts 3 days before expiry gives you a weekend firefight. The failure is the same — the detection window is entirely a monitoring choice.
DNS record monitoring. A DNS record change immediately affects all users in propagated regions. Monitoring for unexpected record value changes detects misconfiguration or supply-chain attack within minutes of the change occurring, rather than waiting for users to report that the site is unreachable.
Heartbeat/cron monitoring. Scheduled jobs that run without producing errors, but simply stop running, are invisible to HTTP uptime monitors. A heartbeat monitor that expects a regular ping from your job fires an alert when the ping doesn't arrive — detecting job failure without waiting for downstream consequences.
Threshold-Based Alerting: The Core of Proactive Detection
Threshold-based alerting fires when a metric exceeds a defined value, before that metric reaches failure level. The design principle is: set your alert threshold at the point where investigation is warranted, not at the point where failure is confirmed.
Alert threshold design:
| Signal | Reactive threshold | Proactive threshold | |---|---|---| | HTTP response code | Non-2xx/3xx | — | | Response time | Timeout (30s+) | >500ms (or 80% of SLA) | | SSL expiry | Expired | 30 days before expiry | | DNS record value | Resolution failure | Any unexpected change | | Check failure count | 1 failure | — | | Consecutive failures | — | 2 of 3 checks fail |
The proactive thresholds fire earlier — often when there's nothing obviously wrong yet. This is intentional. The goal is investigation time before user impact, not confirmation after it.
Trend Monitoring: Catching Slow Degradation
Some failures don't spike — they drift. A memory leak increases response time by 2ms per hour. A growing database table without proper indexing adds 10ms per week to a query. A CDN edge cache filling up degrades offload rates over days.
Trend monitoring compares current performance to a historical baseline:
- "Response time is 40% higher than the 7-day rolling average"
- "Error rate has increased steadily for the past 2 hours"
- "Response time has been consistently above 300ms for 90 minutes"
Trend alerts are more complex to configure than absolute thresholds but catch categories of failure that threshold alerts miss entirely. They are particularly valuable for services with variable baseline performance (traffic-dependent latency, batch processing jobs) where a fixed threshold would produce too many false positives.
Health Check Design for Early Warning
The health check your monitoring probes is as important as the monitoring configuration. A health check that returns HTTP 200 regardless of internal state is useless for proactive detection.
Shallow health checks (bad for proactive monitoring): return 200 if the process is running. Catches only process death.
Deep health checks (good for proactive monitoring): verify internal subsystems and report their status. A good deep health check:
- Executes a test database query and reports its latency
- Checks the queue depth and reports whether it's above normal
- Verifies connectivity to critical external dependencies
- Returns a degraded status (200 with a body indicating partial health) when subsystems are slow but functional
When your deep health check returns a degraded status, your monitoring can fire an early warning alert — your service is technically up but showing internal stress. This is exactly the signal proactive monitoring is designed to surface.
How Vigilmon Enables Proactive Alerting
Vigilmon includes several features specifically designed for proactive detection:
Response time thresholds — set per-endpoint response time alerts below failure level. Vigilmon fires when response time exceeds your threshold, not just when requests time out.
Response time history — view response time trends over 24 hours, 7 days, or 30 days to identify gradual degradation and correlate it with deployments.
SSL certificate expiry alerts — configurable alert windows (e.g., 30 days before expiry, 7 days before expiry) give you advance notice before certificates become a user-visible problem.
DNS record value monitoring — alert on any change to a monitored DNS record, not just resolution failures.
Multi-region consensus — Vigilmon requires multiple geographic probes to agree on a failure before alerting. This reduces false positives from transient single-probe issues, so your proactive alerts are signal rather than noise.
Keyword monitoring — check that specific content appears in the response body. A page that returns 200 but is missing critical content (e.g., your checkout form, your login button, or a content block that indicates the CMS is working) can be caught before users report a blank or broken page.
Building a Proactive Monitoring Stack
A complete proactive monitoring setup covers:
- HTTP monitors with response time thresholds for all user-facing endpoints
- DNS monitors with value checking for your primary domain and critical subdomains
- SSL monitors alerting at 30 days and 7 days before expiry
- TCP port monitors for non-HTTP services (databases, caches, message queues exposed to internal services)
- Keyword monitors for pages where content correctness matters
- Heartbeat monitors for scheduled jobs and background tasks
The goal is coverage of every failure mode that matters to users, with alert thresholds calibrated to fire during the degradation phase — before users experience impact.
Reactive monitoring is the floor. Proactive monitoring is the standard your users deserve.
Set up proactive monitoring with Vigilmon — free tier includes 5 monitors with 1-minute check intervals, response time tracking, and SSL expiry alerts.