The tradeoff
Higher frequency (30s–1min):- Faster detection (problems caught in under a minute)
- More data points for latency trending
- More API calls and higher monitoring cost
- More chances for transient false positives
- Lower cost and less load on your infrastructure
- Fewer false positives from transient network issues
- Slower detection (minutes before you know about an outage)
- Less granular performance data
Guidelines by service type
Matching frequency to SLA
Your monitoring frequency should be fast enough to detect violations within your SLA window:
The rule of thumb: your check frequency should be at most half the time budget you can tolerate for detection.
Reducing noise at high frequency
High-frequency checks can trigger false positives from transient issues. Mitigate this with:Multi-region confirmation
Require failures from 2+ regions before creating an incident. A single-region failure might be a network path issue, not a real outage.Consecutive failure thresholds
Require 2–3 consecutive failures before alerting. One failed check followed by a success is likely transient.Severity-based frequency
Use different frequencies for different alert severities:- Critical monitors at 30s with strict assertions
- Warning monitors at 5min with relaxed thresholds
Cost considerations
More frequent checks mean more API calls and data storage. Calculate your monitoring budget:DevHelm frequency range
DevHelm supports check frequencies from 30 seconds to 86,400 seconds (24 hours). Set the frequency in your monitor configuration or YAML:Reducing false positives
Combine frequency with confirmation strategies.
Incident policies
Configure trigger rules and confirmation.