# How Often Should You Check a Website?
The right interval is the slowest schedule that still catches outages before customers complain. One minute is not always better. Match interval to how fast failure hurts and how much confirmation you use.
Author: fajita-editorial
Published: 2026-07-17
Updated: 2026-07-17
Last reviewed: 2026-07-17
Version: 1
Canonical: https://fajita.io/blog/how-often-should-you-check-a-website
Check interval is a product decision disguised as a monitoring setting. Faster checks detect outages sooner. They also multiply false positives, burn check budget, and tempt you to page on noise. The goal is not the shortest interval. The goal is the slowest interval that still protects customers.

## Start from customer pain speed

Ask how long a total outage can run before someone emails support or posts on social. If the answer is five minutes, a fifteen minute interval is too slow unless you confirm failures quickly. If the answer is thirty minutes, aggressive one minute checks may be wasted spend.

- Marketing site for a small SaaS: five minute interval is often enough
- Login or checkout path: one to two minutes with confirmation
- Internal admin tools: five to fifteen minutes unless revenue depends on them
- Status page itself: one to five minutes so the page reflects reality

## Factor in confirmation

Fajita verifies failures before opening incidents. That means your effective detect delay is interval times confirmation count, not interval alone. A five minute monitor that confirms after two failures can still catch many outages within ten minutes while ignoring single blips.

| Interval | Confirm after 2 failures | Approx worst-case detect |
| --- | --- | --- |
| 1 minute | 2 checks | 2 minutes |
| 5 minutes | 2 checks | 10 minutes |
| 15 minutes | 2 checks | 30 minutes |

## Watch check budget

Every completed check counts toward your monthly allowance. Ten monitors at one minute intervals consume roughly 430,000 checks per month before retries. The same ten monitors at five minute intervals consume roughly 86,000. Interval choice directly affects plan fit.

## Recommended defaults

1. Public marketing site: five minutes, confirm before alert
2. Authentication or billing API: one to two minutes with JSON assertions
3. Background cron work: heartbeat URL with grace period instead of polling the job
4. Staging environments: fifteen minutes or paused unless you actively test

Revisit intervals after your first real incident. If customers noticed before monitors, tighten the schedule or add a second probe from another angle. If you only alert on confirmed failures and still get noise, slow down before you mute channels.
Original contribution: Interval selection framework: customer pain speed, confirmation multiplier, and check budget in one decision.