--- title: "Nobody Is Watching Your App Right Now" description: "Your app can break at 2am and nothing will tell you. Here is how monitoring works, what it can't do, and which tool fits a non-engineer." url: https://www.fomio.ai/blog/nobody-is-watching-your-app-right-now published: 2026-09-27T18:00:00.241+00:00 updated: 2026-09-27T18:00:00.241+00:00 topic: basics words: 2038 --- # Nobody Is Watching Your App Right Now A plain-English guide to the second computer that checks your app on a schedule and tells you when it stops working. **In short:** - Monitoring is just a second computer, somewhere else, opening your app on a schedule and telling you when it doesn't open. - Nothing you already use — not your building tool, not your host — is watching your app for you. - The gap between checks is the real thing you're buying: it's the worst case for how long you stay in the dark. - A homepage that loads can still hide a broken login or a dead database. - Once it's set up, break your app on purpose once and check the email actually arrives. ### What is uptime monitoring? Uptime monitoring is a second computer, somewhere else, that opens your app on a schedule and tells you when it doesn't open. A monitor repeatedly checks that a page or service is online and working as expected, and sends an alert when it finds a problem. The point is hearing it from the tool, not from your customers. 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[^3]. 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. > **Why one check isn't the whole story** — Running an app means depending on a pile of separate things — hosting, software, and third-party services for delivering files and handling logins — and a problem in any one of them shows up as downtime[^2]. A monitor checking your homepage catches a lot. It does not automatically catch everything. ## 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." - **Every 30 seconds** — How often UptimeRobot can check, at its fastest setting [^1] - **3 in a row** — Failures Sentry waits for before raising an issue [^4] 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[^1]. 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[^6]. 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[^4]. 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. *Four ways to find out your app has stopped working* | Tool | How often it checks | What it tells you | Who it fits | | --- | --- | --- | --- | | UptimeRobot | As often as every 30 seconds, as slow as five minutes[^1] | Up or down, on a dashboard with incidents you manage yourself | Anyone happy to set up checks and decide what counts as failure | | Pingdom | Scheduled checks from chosen regions[^6] | Follow-up tests that help establish the cause[^6] | Teams with someone technical and users spread worldwide | | Sentry | Every minute, flagged after three failures in a row[^4] | The failure plus related errors and a timeline[^4] | People who read code and want the errors alongside | | Fomio | Every five minutes free; every minute on Builder and Pro | Working, Having trouble or Down, plus plain-language cause — and on paid plans a prompt for your AI tool | People who built an app without choosing the stack underneath it | 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. **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. **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. **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. **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. **Paste this into your AI tool** ```text 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. ## Questions people also ask ### Does my hosting provider already monitor my app? No. Hosts, databases and the tools you build with all publish status pages about their own problems, and those are useful. But none of them are opening your specific app and checking that it loads, and none of them will contact you when your app breaks for reasons of its own. A bad change you deployed, an expired setting or a dead login flow will not show up on anyone's status page but yours. ### What if my homepage loads but the app doesn't work? This is the most common blind spot. A check on your homepage confirms the front door opens, not that anything inside works. Running an app means depending on hosting, software and third-party services for things like files and logins, and a failure in any one of them can leave a perfectly loading page where nothing saves. If the logged-in experience matters, you'll want a tool that can check more than the front page, or you'll want a way for users to tell you fast. ### Is checking every five minutes good enough? For a side project or something with a handful of users, yes — five minutes of not knowing is not going to change the outcome. For an app people pay for or rely on during working hours, once a minute is worth having, because it turns a long quiet outage into a short one you caught early. Start with whatever is free, see how often you actually get alerts, and move up if the wait ever feels too long. ### Will monitoring wake me up for nothing? Sometimes, and the better tools work to avoid it. A single failed check can mean the checking computer had a bad moment rather than your app. That's why Sentry, for example, only raises an issue after three consecutive failures at one-minute checks. If a tool emails you the instant anything looks odd, you'll start ignoring the emails, which defeats the purpose entirely. ### Will a monitor tell me how to fix the problem? Most won't. They tell you the door didn't open and leave the diagnosis to you, though some go further — Pingdom runs follow-up tests to help establish the cause, and Sentry shows related errors next to the failure. Fomio describes in plain language what likely went wrong, and on its paid plans writes a prompt you can paste into the AI tool you built the app with. Either way, the fixing is still yours. ## Sources [^1]: UptimeRobot: Free Website Monitoring Service — UptimeRobot. https://uptimerobot.com/ [^2]: From Downtime to Uptime: Monitoring Tools and Techniques for Systems, Websites, APIs, and More — Splunk (2025-06-06). https://www.splunk.com/en_us/blog/learn/uptime-monitoring.html [^3]: What Is Uptime? – IT Glossary — SolarWinds. https://www.solarwinds.com/resources/it-glossary/uptime [^4]: Uptime monitoring for developers — Sentry. https://sentry.io/product/uptime-monitoring/ [^5]: What is Uptime Monitoring? — PingHome. https://www.pinghome.io/guides/what-is-uptime-monitoring/ [^6]: Uptime Monitoring — Pingdom (2025-05-07). https://www.pingdom.com/product/uptime-monitoring/ [^7]: Uptime.com Website Monitoring Service — Uptime.com. https://uptime.com/ [^8]: What Is Uptime Monitoring (and Why It Matters) — SSL Shopper (2026-01-06). https://www.sslshopper.com/website-monitoring/what-is-uptime-monitoring/