How do check intervals and credits work?
Understand how check intervals affect credit consumption and choose the right frequency for your monitors.
The check interval controls how often UpCanary runs a monitor. Shorter intervals mean faster detection of outages but higher credit consumption. Choosing the right interval is a balance between how quickly you need to know about problems and how many credits you want to spend.
Available Intervals
| Interval | Checks per Hour | Checks per Day | Checks per Month |
|---|---|---|---|
| 30 seconds | 120 | 2,880 | ~86,400 |
| 1 minute | 60 | 1,440 | ~43,200 |
| 2 minutes | 30 | 720 | ~21,600 |
| 5 minutes | 12 | 288 | ~8,640 |
| 10 minutes | 6 | 144 | ~4,320 |
| 15 minutes | 4 | 96 | ~2,880 |
| 30 minutes | 2 | 48 | ~1,440 |
| 1 hour | 1 | 24 | ~720 |
Monthly figures assume 30 days.
Credit Math
1 check = 1 credit, regardless of:
- How many regions run the check
- What monitor type is used (HTTP, TCP, DNS, Ping)
- How large the response is
This means the monthly credit cost of a monitor equals its monthly check count. A monitor running every 5 minutes costs ~8,640 credits per month. A monitor running every 30 seconds costs ~86,400 credits per month.
Example Monthly Costs
| Monitor | Interval | Monthly Credits |
|---|---|---|
| Production API | 1 minute | ~43,200 |
| Company website | 5 minutes | ~8,640 |
| Staging environment | 10 minutes | ~4,320 |
| DNS / domain check | 1 hour | ~720 |
If you have 10 monitors all at 5-minute intervals, that’s roughly 86,400 credits per month total.
Choosing the Right Interval
30 seconds - 1 minute: Critical production services
Use the shortest intervals for services where every second of undetected downtime has a direct business impact:
- Payment processing endpoints
- Authentication and login APIs
- Core application APIs that users interact with in real time
- Services with strict SLA commitments
At 30 seconds, you’ll know about an outage within half a minute. At 1 minute, within a minute. These are appropriate when your mean time to detect (MTTD) matters.
5 minutes: Standard production monitoring
The default recommendation for most production services:
- Company websites and marketing pages
- Non-critical API endpoints
- Admin dashboards
- Documentation sites
5 minutes gives a good balance between responsiveness and credit consumption. Most outages that last less than 5 minutes don’t warrant an alert anyway.
10 - 15 minutes: Internal and lower-priority services
- Internal tools and dashboards
- Development or QA environments
- Third-party integrations you don’t control
- Services with a relaxed SLA
30 minutes - 1 hour: Background health checks
- DNS record monitoring
- SSL certificate expiry checks
- Domain availability checks
- Infrequently-used services
Certificate expiry and DNS record changes rarely happen on a minute-by-minute basis. Checking once per hour is more than sufficient and costs very few credits.
Mean Time to Detect
Your check interval directly determines your worst-case mean time to detect (MTTD). If a monitor runs every 5 minutes and your service goes down 1 second after a check passes, you won’t know for up to 4 minutes and 59 seconds.
Worst-case MTTD = 1 × interval
For critical services, factor this into your incident response planning and choose an interval that fits your acceptable detection window.
Changing Intervals
You can change a monitor’s interval at any time without losing historical data. The new interval takes effect on the next scheduled check. Credit consumption adjusts immediately to the new rate.
Related Documentation
- Monitor Overview - All monitor types and their capabilities
- Credits - How the credit system works
- Plans - Credit allowances by plan
- Monitoring Regions - How regions multiply credit usage