What Uptime Check Interval Should Your Website Use?

Most small sites and side projects only need a 5-minute uptime check interval; a 1-minute interval is worth paying for once real users depend on the service, because every extra minute of undetected downtime is a minute they might discover the outage before you do. A 5-minute interval caps worst-case detection time at just under five minutes; a 1-minute interval cuts that to just under one minute. The right interval is the shortest one you can afford that still catches an outage before your customers, or your boss, notice it first.

Pingwire is a developer-first monitoring and notification platform: point it at a URL, and it checks that URL on your configured uptime check interval, then pushes an alert to your phone or a channel the moment a check fails. An uptime check interval is simply the fixed gap between two consecutive automated checks of that URL — set it too long and you find out about outages late; set every monitor to the fastest setting and you burn through monitor capacity you don't need on pages that never break.

What Is An Uptime Check Interval?

An uptime check interval is the fixed amount of time a monitor waits between one check of your site and the next. It is the single biggest lever on how fast you find out about a real outage, because the monitor cannot alert you any faster than the gap between its own checks plus the time it takes to confirm the failure and send the alert.

Two intervals dominate in practice: 5 minutes and 1 minute. A 24-hour period on a 5-minute interval runs 288 checks; the same period on a 1-minute interval runs 1,440 — five times the checks, for a monitor that is otherwise identical. That's the real cost of a faster interval: it isn't harder to set up, it's just more checks running against your infrastructure and more monitor capacity spent.

Detection Time By Interval

The table below shows the practical tradeoff. "Worst case" is the outage starting one second after a check passes — the monitor won't see the problem until its next scheduled check.

Interval	Worst-case detection time	Typical use case
5 minutes	~5 minutes	Side projects, internal tools, low-traffic sites
1 minute	~1 minute	Anything customers pay for or depend on daily

If you haven't set up any downtime alerting yet, start with how to get notified when your website goes down, then come back here to tune the interval once it's running.

How Do You Choose The Right Interval For Your Site?

Don't set every monitor to the fastest interval by default. Work through your endpoints one at a time instead:

1. List every URL or endpoint whose downtime costs you money or trust.
2. For each one, estimate what a 5-minute outage actually costs — a lost signup, a support ticket, or genuinely nothing.
3. If the honest answer is "nothing at all," leave it on a 5-minute interval.
4. If the cost is real, move that one endpoint to a 1-minute interval and leave the rest alone.
5. Re-check the list every time you ship a paying feature — the right answer changes as the product grows.

This keeps your fastest checks pointed at the things that are actually worth watching closely, instead of paying the same attention to a marketing page and a payment webhook. A landing page that's been static for months rarely needs the same interval as a checkout endpoint that processed a sale an hour ago.

How Many Monitors Do You Need At Each Interval?

This is also a plan question, not just a technical one. Pingwire's free plan gives you 3 monitors on a 5-minute interval with 7 days of history — enough to cover a personal site, a side project API, and one status page without paying anything. The paid plan raises that to 25 monitors on a 1-minute interval with 90 days of history, which is built for someone running several services where a few of them genuinely need the faster check.

Most teams don't need all 25 monitors on the fast interval even once they upgrade. The right move is still the ranked list from the steps above: put the two or three endpoints that actually matter on the 1-minute interval, and leave the rest slower. A monitor list where every entry is "critical" usually means nobody has done the ranking yet.

When Should You Move From 5-Minute To 1-Minute Checks?

Running your own curl-in-cron script works fine until you also need the alert itself to be reliable. A paging script has to handle retries, avoid spamming you for one slow response, and reach a device that's actually online — which is a second project on top of the check itself.

#!/usr/bin/env bash
URL="https://example.com/health"
if ! curl -fsS -o /dev/null -m 10 "$URL"; then
  echo "DOWN: $URL did not respond in 10s" >&2
  exit 1
fi

Run that on a cron line every five minutes and you have a homemade 5-minute uptime check — but the exit code still has to reach a phone somewhere, and a naive version of that script will page you every five minutes for as long as the outage lasts unless you also build dedupe logic. Pingwire's uptime monitoring runs the check on your chosen interval and handles that delivery as web push, with no separate alerting pipeline to babysit.

See how uptime monitoring works if you want the interval and the delivery handled together.

What About Checking Things That Aren't A URL?

Cron jobs, backup scripts, and scheduled batches don't have a URL to poll, so the interval logic flips. Instead of your monitor calling out on a schedule, your job calls in on its own schedule, and the alert fires only when a call-in is missed. That's heartbeat monitoring, and it uses the same interval thinking in reverse — a job that runs hourly should have a grace window measured in minutes, not the same five-minute default you'd use for a website, or every slightly-late run turns into a false alarm.

Do More Frequent Checks Cause False Alarms?

The most common reason teams stick with a slow interval is habit, not cost. If you're not sure whether a faster interval is worth it, use the ranking from the steps above: only move an endpoint to a 1-minute interval if it lands solidly in the "this costs real money or trust" column. If none of your endpoints land there, a 5-minute interval is the right choice, not a compromise you're settling for.

A shorter interval on its own doesn't create false alarms — a check with a request timeout longer than the interval does, because a single slow response can overlap the next scheduled check and make the monitor report the site as down when it was only slow. Keep the request timeout a few seconds shorter than the interval, and treat one occasional slow response as noise, not an incident.

Get The Interval Set Up On The Site That Actually Needs It

Add one URL to Pingwire's uptime monitor list and pick the interval — 5 minutes on the free plan, 1 minute if the site needs to be faster than that. Create a free account and watch the first check run within a minute of saving it.