Monitoring Check Intervals: How Often Should You Check?

Check interval is one of the most important — and most misunderstood — settings in uptime monitoring. Too infrequent and you miss outages for minutes. Too frequent and you generate unnecessary load and potentially trigger rate limiting. Getting this right depends on your endpoint type, your business requirements, and your incident response capability.

What Check Interval Actually Means

A 1-minute check interval means your monitoring system sends a request to your endpoint every 60 seconds. If an outage starts at 10:00:05 AM, the next check runs at 10:01:00 AM. If it fails, and your system requires 2 consecutive confirmations, you won't receive an alert until approximately 10:02:00 AM.

The practical detection time is:

Max detection time = (Check interval × Confirmation count) + Alert delivery latency

Example (1 min interval, 2 confirmations, 15 sec delivery):
1 min × 2 + 15 sec = 2 min 15 sec max detection time

With 30-second intervals, that same calculation yields about 75 seconds. The difference matters most when every minute of downtime costs real money.

The Trade-offs of Check Frequency

Faster Checks (30 seconds – 1 minute)

Pros:

• Faster detection and alerting
• More granular uptime percentage data
• Better resolution for incident timeline reconstruction
• Essential for revenue-critical endpoints

Cons:

• Higher load on your endpoints (though typically negligible)
• More data storage required
• Slightly higher cost on per-check pricing plans

Slower Checks (5 minutes – 15 minutes)

Pros:

• Lower load generation
• Sufficient for non-critical services
• Lower cost on usage-based plans
• Fewer check-in alerts to process

Cons:

• Slower detection — a 5-minute outage might resolve before your monitor catches it
• Less useful for SLA measurement (can't prove 99.9% uptime with 5-minute samples)
• Missed short outages that users still experienced

Recommended Intervals by Endpoint Type

| Endpoint Type | Recommended Interval | Reason | |--------------|---------------------|--------| | Payment/checkout | 30 seconds | Direct revenue impact | | Authentication/login | 30 seconds – 1 minute | Blocks all users | | Core API (production) | 1 minute | Mission-critical | | Homepage | 1 minute | First impression | | Key landing pages | 1–5 minutes | Marketing/SEO impact | | Admin interfaces | 5 minutes | Internal, lower urgency | | Staging environments | 5–15 minutes | Development signal | | Internal tools | 10–15 minutes | Convenience features | | Batch job health endpoints | 15–30 minutes | Async processes |

The Case for 30-Second Intervals

Most monitoring tools offer 1-minute intervals as their fastest option. AzMonitor provides 30-second intervals because the gap matters more than it seems.

Consider an e-commerce site processing $500,000/day in orders:

• Revenue per second: ~$5.79
• 30-second faster detection per incident × 20 incidents/year = 600 seconds saved
• Revenue protected: ~$3,470/year

That math gets more compelling for higher-revenue businesses. For companies processing millions per day, 30-second monitoring versus 1-minute monitoring saves meaningful money annually.

Check Intervals and False Positives

There's a counterintuitive relationship between check frequency and false positive rate. Very frequent checks (under 30 seconds) without proper multi-location confirmation can generate false positives from transient network conditions. A single check that fails due to a momentary network hiccup shouldn't fire an alert.

The right approach is to combine fast check intervals with confirmation requirements:

30-second interval + 2-location confirmation + 2 consecutive failures required
= Alert fires ~2 minutes after real outage begins
= False positive rate < 0.1%

This gives you fast detection without alert noise. See our guide on eliminating false positives for the complete strategy.

Check Intervals for SLA Measurement

If you're measuring uptime to report on SLA compliance, your check interval determines the resolution of your uptime percentage calculation.

With 5-minute intervals and 365 days:

• Total checks per year: 105,120
• One failed check = 0.00095% downtime impact
• A 1-hour outage = 12 failed checks = 0.0114% downtime

With 1-minute intervals:

• Total checks per year: 525,600
• One failed check = 0.00019% downtime impact
• A 1-hour outage = 60 failed checks = 0.0114% downtime

The math works out similarly for actual outage measurement, but the granularity of data is much better with shorter intervals. For SLA reporting, shorter intervals give you more defensible data with higher time resolution.

Multi-Step and Synthetic Checks

For multi-step monitoring (simulating a user journey through login → feature → checkout), check frequency depends on test execution time. A browser-based synthetic test that takes 2 minutes to complete can't run every 30 seconds. For synthetic tests, 5-15 minute intervals are typical and appropriate.

This is why synthetic monitoring and uptime monitoring serve complementary roles — use fast uptime checks for availability detection and less-frequent synthetic tests for user journey validation.

Practical Configuration Recommendation

For most teams, this configuration covers the major use cases:

# Critical production endpoints
payment_flow:
  interval: 30s
  confirmation_locations: 3
  consecutive_failures: 2

login_endpoint:
  interval: 30s
  confirmation_locations: 3
  consecutive_failures: 2

core_api_health:
  interval: 1m
  confirmation_locations: 2
  consecutive_failures: 2

# Standard endpoints
homepage:
  interval: 1m
  confirmation_locations: 2
  consecutive_failures: 2

# Lower priority
admin_panel:
  interval: 5m
  confirmation_locations: 2
  consecutive_failures: 3

AzMonitor supports per-monitor interval configuration, so you can apply different frequencies to different endpoints within the same account. Start with a free trial and adjust intervals as you learn your failure patterns.