> ## 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>