How Often Should You Check Your Website Is Up?

Every uptime monitoring tool asks you the same question during setup, and almost nobody has a reasoned answer: how often should we check this? The instinct is to pick the smallest number on offer, on the theory that faster is better. That instinct is half right, and the other half costs you either money or sleep.

Check frequency buys you one thing. It shortens the gap between the moment your site breaks and the moment you find out. Everything else people believe about intervals is folklore.

What an interval actually controls

A monitor is a loop. Every N seconds it makes a request and writes down what happened. If the site falls over one second after a successful check, nobody knows until the next one runs.

So on average you learn about an outage after half your interval, and in the worst case after a full interval. That is the entire mechanism.

Notice what is missing from that table: any mention of accuracy. A five-minute monitor catches every outage a thirty-second monitor catches, provided the outage lasts longer than five minutes, and almost all of them do. The only difference is how long it takes to hear about it, and that difference is measured in minutes.

Confirmation adds to the delay

Detection is only the first step. Before a responsible monitor wakes you up, it should confirm the failure is real. Barkme retries a failed request after two seconds, and waits for two consecutive failed checks before opening an incident. That is four failed requests before anything reaches your phone.

That confirmation window sits on top of your interval:

• A 30-second monitor alerts in roughly a minute.
• A 5-minute monitor alerts in five to ten minutes.

The incident itself is backdated to the first failed check, so the confirmation window still counts against your uptime figures. The alert arrives a little later and the number stays honest.

Pick the interval from the cost of a minute

Forget how fast you can check. The useful question is what an extra minute of unnoticed downtime actually costs you. For most sites the honest answer is nothing measurable.

This is the rule of thumb I use.

30 seconds for anything that takes money

Checkout flows, payment callbacks, booking engines, live APIs that other companies build on. If a minute of silence means abandoned carts or a breached SLA, pay for the fastest interval and stop thinking about it. The arithmetic is trivial. If a minute of downtime costs more than the plan does, the plan is free.

1 minute for anything customer-facing

Marketing sites, dashboards, documentation, app front ends. One minute is fast enough that you will almost always know before a customer emails you, and slow enough that you are only paying for precision you can act on. If you are unsure, choose this.

2 to 5 minutes for internal and low-stakes

Staging environments, internal tools, cron endpoints, the blog. Nobody is filing a ticket in the first five minutes, and nobody should be paged either. Five minutes also suits endpoints that are genuinely slow or expensive to serve.

The reasons to slow down

Faster checking has costs, and they are rarely on the invoice.

You are generating real traffic. A 30-second monitor makes 2,880 requests a day. Point six of those at the same origin and you have added 17,000 requests a day to your logs, your analytics noise, and any rate limiter sitting in front of the app.

You are hitting whatever the endpoint hits. If the monitored URL runs database queries or calls a third-party API, you are paying for those too, every thirty seconds, forever. Point the monitor at a cheap health-check route and leave the heavy pages alone.

Short intervals amplify flapping. A site that fails one request in fifty will produce more failed checks per hour at 30 seconds than at 5 minutes. Confirmation logic absorbs most of that, but a marginal host will still surface more noise on a fast interval. If a monitor keeps opening and closing incidents, the interval is the symptom and the host is the disease.

Set the timeout separately

Interval and timeout answer different questions. The interval is how often to ask. The timeout is how long to wait for an answer before calling the request failed.

Barkme lets you set a timeout of 1 to 120 seconds per monitor, and the default suits most sites. The two settings only interact at the edges. A timeout longer than the interval means a slow response can still be in flight when the next check starts. If your endpoint genuinely takes 45 seconds to respond, a 30-second interval is the wrong tool, and the response time is the thing to fix.

A good habit is to set the timeout at roughly three times your normal response time. That way a genuine stall trips it while ordinary variance sails through.

A sensible starting configuration

If you are setting up monitoring today and want to stop deliberating:

1. Every public page a customer can land on: 1 minute.
2. Checkout, sign-in, and any API another business depends on: 30 seconds.
3. Staging, internal dashboards, and background job endpoints: 5 minutes.
4. Set every timeout to about three times the endpoint's normal response time.
5. Point monitors at a lightweight health route.

Then leave it alone. Interval tuning has a very low ceiling. The time is better spent on the things that actually cause outages, like expired certificates, expired domains, and alerts nobody reads.

Those get their own posts. Start with the expiry dates that quietly take sites down, then read why most uptime alerts are noise.

If you want the full picture of how checks, incidents and alerts fit together, how Barkme works walks through the whole pipeline, and the F.A.Q answers the specifics.