How often should your app be checked?

You shipped something. People use it. And there's a question sitting at the back of your head that you can't quite phrase, which is roughly: if this broke right now, how long would it be before I knew?

That's the real question. "How often should my app be checked" is just the version of it you can type into a search box. The reasoning below is what lets you pick a number for your app instead of copying someone else's.

Why does the number matter so much?

How often something looks at your app sets the worst case for how long it can be broken while you're cheerfully unaware. A five-minute gap means up to five minutes of downtime nobody has noticed. A thirty-minute gap means half an hour where your app might be showing a blank white screen to everyone who opens it, and you are at lunch.

The standard for anything with real users has settled around once a minute. Faster looks of fifteen to thirty seconds are kept for the most critical parts, and five minutes or slower is fine for low-priority things where a few extra minutes of not knowing doesn't hurt.³

That maps cleanly onto what the tools sell. UptimeRobot looks every five minutes on its free plan, every minute on Solo and Team, and every thirty seconds on Scale.² Better Stack's free tier covers ten things at three-minute gaps.⁷ Everyone is selling the same thing: speed of finding out.

Why is it slower than the number says?

Most tools don't tell you the first time a look fails. They wait to see it fail a few times in a row, so one blip on the internet doesn't wake you at 3am for nothing. Sensible — but it multiplies.

Sentry's documentation spells the maths out: the default is three failures in a row before it raises anything, and with a five-minute gap plus that default, you find out after fifteen minutes of continuous downtime.¹ Fifteen minutes, from a tool advertised as checking every five.

So the number you actually care about isn't how often it looks. It's how long from broken to you knowing. That's the gap multiplied by however many failures it wants first. At once a minute with two failures needed, you're told in about two minutes. That's a good place to be.

How do I pick my number?

Ask one question: what happens in five minutes of my app being down? It isn't a technical judgement. It's a question about your users that only you can answer.

1. 1
   If the answer is "roughly nothing"

   Your users are twelve people in a group chat and they'd text you. Five minutes is genuinely fine, and free plans exist for exactly this — most credible tools publish one covering a handful of basic checks at five-minute gaps, which is enough for a single site.
2. 2
   If the answer is "someone sees an error and never comes back"

   You want once a minute. This is most apps with actual traction, and it's the default worth paying for.
3. 3
   If money moves

   Checkout, payments, a login that gates paid features. Thirty-second gaps are the recommendation where every minute of downtime has measurable business impact.
4. 4
   Then do the multiplication

   Find out how many failures in a row your tool wants before it says anything, and multiply. That's your real answer, not the one on the pricing page.

Is faster always better?

No, and there are two honest reasons. The first is false alarms: the internet is lumpy, a single look from a single place will occasionally fail for reasons that have nothing to do with your app, and the more often you look the more of those you collect.

A sensible starting setup for a normal production web app is a look every minute, confirmation from two regions, a ten-second timeout, and two failures in a row before anything is said.³

The second is cost. Going from five minutes to one minute is a real improvement. Going from one minute to thirty seconds saves you thirty seconds, and usually costs a tier. Decide whether thirty seconds is worth it for what you built. Often it isn't.

Which tool should I use?

Here's the comparison. We build one of these, so treat that accordingly and check the numbers yourself.

Where the others are better, plainly: more places on the map to look from, more things watched on a free plan, longer histories at the top end, and the option of being phoned or texted. Fomio tells you by email — not SMS, not WhatsApp, not Discord. If you need a phone call at 4am, buy one of the others. That's a real answer, not false modesty.

Where Fomio is different: the tools above were built for people who already know what a status code is, and their setup screens read like it. They ask how often to look, what counts as a failure, how many regions to confirm from. Everything you just read is, in effect, homework those tools set you.

Fomio takes a link and works out what to watch. There's nothing to configure. It reports one of three things — Working, Having trouble or Down — and when something breaks it says in plain language what likely went wrong. On Builder and Pro it also writes the prompt to paste into the tool you built the app with, which matters when the gap between knowing it's broken and knowing what to type is the actual problem.

Free is one app, looked at every five minutes, seven days of history, no card. Builder is three apps every minute with the fix prompts and thirty days of history. Pro is fifteen apps every minute, a status page your users can look at, and a year of history. Current prices are at fomio.ai/pricing.

My deployed app is returning an error page instead of loading. Here's what the error says: [paste it]. Find the cause in this codebase, explain it in one paragraph, and make the smallest change that fixes it. Don't refactor anything else.

What should I do today?

Pick your number with the five-minute question, then find out how many failures in a row your tool wants before it says anything. If you're running something quiet, five minutes on a free plan is a complete answer and you can close this tab.

If people you don't personally know are using your app, move to once a minute. The gap between down for two minutes and down for an hour because it was Saturday is the entire reason any of this exists.