Nobody Is Watching Your App Right Now

Your app is running on a computer you have never seen, in a building you could not find on a map, and right now you have no idea whether it is working. You could check. You could open it in a browser, watch it load, and feel fine for about four minutes. Then you close the tab and you are back to not knowing.

That gap — between your app breaking and you finding out — is the entire problem. Everything below is about closing it.

The word "uptime" just means the app is up: reachable, loading, doing its job. "Downtime" is the opposite. Monitoring is the part where something other than you is paying attention³. Think of it as a smoke alarm rather than a fire brigade. It doesn't fix anything. It shouts.

Why don't I already have this?

Nothing is watching the app you shipped. Not the tool you built it with, not the place it's hosted, not your database.

They all have status pages for their own problems. None of them are looking at your app, and none of them will message you when your app stops working.

So your app can be broken for nine hours overnight and the only sign will be an email from a user the next morning that starts "hey, is it just me or…" That email is the thing you're trying to never receive again.

What does "working" actually mean?

A monitor opens your app's address the way a visitor's browser would, and waits to see what comes back. There are three broad outcomes, and only one of them is good news.

Something normal comes back. The page loads. Nothing happens, no email, you carry on with your day.

Nothing comes back. No answer at all, or the answer takes so long the monitor gives up. That's the classic down: hosting fell over, the address stopped pointing anywhere, the whole thing is dark.

Something bad comes back. The server answers, but the answer is an error rather than your app. This is the confusing one, because the app is technically alive. It's awake. It's just handing every visitor a wall of grey text instead of your homepage.

And then there's the case that catches out almost everyone. The homepage loads perfectly. But the database behind it is unreachable, so nobody can log in, nothing saves, and every button quietly fails. From the outside, the front door opens. Inside, the building is empty.

How often should it check my app?

A monitor doesn't watch continuously. It checks, waits, checks again. The gap between checks is the worst case for how long your app can be broken before anyone knows.

Check every five minutes and you'll know within about five minutes. Check every minute and you'll know within about a minute. For a side project, five minutes is invisible. For an app people pay for, that difference is the difference between "brief blip" and "it was down through the whole morning rush."

That three-strikes idea is worth stealing as a concept even if you never use Sentry. A good monitor doesn't panic on the first failure. The internet hiccups. A decent tool waits to see if the problem is still there before it tells you.

What can't a monitor do?

It cannot tell you why. It can tell you the door didn't open. Working out that you pushed a change at 11pm, or your database went to sleep, or your AI provider ran out of your credit — that's still on you, with varying amounts of help depending on the tool.

It cannot check things only a logged-in user sees, unless you deliberately set that up, which on most tools means work you probably don't want to do.

It can be wrong. A check can fail because the checking computer had a bad moment, not because your app did. And it doesn't fix anything. It just means you're the one who knows first.

Which monitoring tool should I use?

Most of what's written about this was written for people who run infrastructure for a living, and the tools were built for them too. That's not a criticism of the tools. It's a description of who's holding them.

UptimeRobot is the default answer most people land on. It continuously checks websites and services, alerts you when something goes down or changes, and gives you a dashboard where you can see statuses, pause things and manage incidents¹. Generous free tier, widely used, fine tool. You will be asked to make decisions about how to check and what counts as a failure.

Pingdom is the heavyweight. You can check from specific parts of the world — North America, South America, Europe, Asia, Australia — which matters if your users are concentrated somewhere you aren't⁶. It also runs follow-up tests to help establish the cause, including looking at what your web server returned. That's genuinely more than a simple monitor gives you, and it's priced and designed for teams with someone technical on them.

Sentry sits alongside error tracking, so when a check fails it shows you the related errors and a timeline next to it⁴. Powerful if you read code. Less useful if you don't.

Fomio — which is us, and now you know — was built for the person who did not choose their stack. You paste a link. It works out what to watch, and there is nothing to configure. When it reports back it says one of three things: Working, Having trouble, or Down. When something breaks it tells you in plain language what likely went wrong, rather than handing you a code to go and look up.

The free plan watches one app from outside, checks every five minutes, emails you when it breaks and keeps seven days of history. No card needed. Builder watches three apps, checks every minute, keeps 30 days and writes a fix prompt you can paste straight into the AI tool you built the app with. Pro watches fifteen apps, keeps a year of history and gives your users a public status page. Current prices are at fomio.ai/pricing.

Where the others are better, honestly: Pingdom checks from more places around the world and digs further into the cause. UptimeRobot can check more often than once a minute and lets you run a lot of monitors free. Several tools will message you by text, phone or chat app. Fomio tells you by email. If you need a phone call at 3am, that's a different tool.

What should I do this week?

1. 1
   Point something at your app

   Genuinely, anything. The gap between zero monitoring and any monitoring is enormous; the gap between two decent tools is small.
2. 2
   Send the alerts somewhere you actually read

   An alert going to an address you check once a week is the same as no alert at all.
3. 3
   Break it on purpose, once

   Change the address to something wrong for two minutes. If the email lands, you have a smoke alarm. If it doesn't, you have a decoration.
4. 4
   Decide what you'd do next time

   Knowing first only helps if you know your first move — roll back the last change, check the database, or ask the tool you built with.

My deployed app is returning an error instead of loading. Walk me through the most likely causes in order, starting with the most recent change I deployed, then the database connection, then any third-party services the app depends on. For each one, tell me exactly what to check and where to look.

When your app does break — it will, everything does — you'll find out from a notification rather than a customer. That's the entire point. It's a small thing, and it changes how it feels to run the app enormously.