Skip to main content
Check frequency balances detection speed against cost and noise. Critical APIs may need 30-second checks; informational pages might need 5-minute intervals.

​
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 frequency (5min–15min):
  • 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

ServiceRecommended frequencyRationale
Revenue-critical API30sEvery second of downtime costs money
Public-facing website1minUsers notice within minutes
Internal dashboard5minStaff can tolerate short delays
Background job health5min–15minJobs have built-in retry logic
Marketing/blog site5min–10minLow urgency, rarely changes
Certificate expiry6h–24hExpiry is days away, not seconds
DNS resolution5minDNS changes propagate slowly

​
Matching frequency to SLA

Your monitoring frequency should be fast enough to detect violations within your SLA window:
SLA targetMaximum detection timeMinimum check frequency
99.99% (4.3min/month)< 1 min30s
99.9% (43min/month)< 5 min1min
99.5% (3.6h/month)< 15 min5min
99% (7.3h/month)< 30 min10min
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: 
Monthly checks = (seconds in month / frequency) × number of monitors × regions
For example: 10 monitors × 2 regions × 60s frequency = ~864,000 checks/month.

​
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: 
monitors:
  - name: Critical API
    frequency: 30
  - name: Blog
    frequency: 300

Reducing false positives

Combine frequency with confirmation strategies.

Incident policies

Configure trigger rules and confirmation.