> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Choosing Check Frequency

> How to choose the right monitoring check frequency for different service types and SLAs

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

| Service | Recommended frequency | Rationale |
| - | - | - |
| **Revenue-critical API** | 30s | Every second of downtime costs money |
| **Public-facing website** | 1min | Users notice within minutes |
| **Internal dashboard** | 5min | Staff can tolerate short delays |
| **Background job health** | 5min–15min | Jobs have built-in retry logic |
| **Marketing/blog site** | 5min–10min | Low urgency, rarely changes |
| **Certificate expiry** | 6h–24h | Expiry is days away, not seconds |
| **DNS resolution** | 5min | DNS changes propagate slowly |

## Matching frequency to SLA

Your monitoring frequency should be fast enough to detect violations within your SLA window:

| SLA target | Maximum detection time | Minimum check frequency |
| - | - | - |
| 99.99% (4.3min/month) | \< 1 min | 30s |
| 99.9% (43min/month) | \< 5 min | 1min |
| 99.5% (3.6h/month) | \< 15 min | 5min |
| 99% (7.3h/month) | \< 30 min | 10min |

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:

```yaml theme={null}
monitors:
  - name: Critical API
    type: HTTP
    config:
      url: https://api.example.com/health
      method: GET
    frequencySeconds: 30
  - name: Blog
    type: HTTP
    config:
      url: https://blog.example.com
      method: GET
    frequencySeconds: 300
```

<CardGroup cols={2}>
  <Card title="Reducing false positives" icon="shield" href="/learn/monitoring/reducing-false-positives">
    Combine frequency with confirmation strategies.
  </Card>

  <Card title="Incident policies" icon="book" href="/incidents/policies">
    Configure trigger rules and confirmation.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.