10 Web App Uptime Monitoring Tools, Sorted by Budget and Need

The best web app uptime monitoring tools for a small team are cheap or free: UptimeRobot, Better Stack or Oh Dear will tell you when the app is down. Pair one of them with an error tracker like Sentry or Flare, and you'll catch most problems before your customers email you about them.

Below are 10 tools I'd consider, grouped by what they monitor, with prices, who each one suits and when to skip it. I work mostly with Laravel and JavaScript, so the list leans toward tools that fit that stack, and since I'm based in the EU, I've noted where each tool can keep your data.

The short answer: which tool does what

My rule of thumb: start with one uptime monitor and one error tracker. That combination catches most outages and bugs. Add background job monitoring once the app sends emails, generates invoices or syncs data on a schedule. Add performance monitoring once you have enough traffic to feel it.

Monitoring is one piece of keeping an app healthy after launch. For how it fits with updates, backups and support, see my guide to web application maintenance.

Uptime monitoring: know when the app is down

An uptime monitor visits your app from the outside at a fixed interval, usually every one to five minutes, and alerts you when it doesn't respond or returns an error. It has to run somewhere other than your app. A monitor on the same server goes down with the thing it's supposed to watch.

The better services also check your SSL certificate (the padlock in the browser) and your domain's expiry date. An expired certificate or domain is one of the most avoidable outages there is, because a reminder a few weeks out would have prevented it. If it happens anyway, here's my step-by-step plan for when your website is down.

1. UptimeRobot: the cheapest place to start

UptimeRobot is a classic first choice. The free plan watches up to 50 URLs every five minutes and includes one status page. Paid plans with one-minute checks start at about €9 a month billed annually. The pricing page pitches the free plan at hobby and non-profit projects, but the current terms say the service is available for any use, including commercial use.

Pick it if you want basic uptime monitoring today without spending anything. Skip it if five minutes is too long to be down without knowing. Once you're paying anyway, compare it with Oh Dear and Better Stack, which cover more than uptime.

2. Better Stack: uptime, status pages and on-call in one place

Better Stack combines uptime checks, status pages, alerting and incident handling. The free plan, which Better Stack labels as being for personal projects, covers 10 monitors and heartbeats with three-minute checks, one status page, and alerts by email and Slack. On-call scheduling, where the alert goes to whoever is on duty, needs a paid responder license at roughly $29-34 a month depending on annual or monthly billing.

Pick it if several people share responsibility for the app, or if your customers need a status page to follow during an incident. Skip it if you're running a small app on your own. You'd mostly be paying for features you won't use.

3. Oh Dear: more than uptime, and a good fit for Laravel

Oh Dear was founded in Belgium by two developers from the PHP and Laravel community. It checks uptime every minute and also watches SSL certificates, domain expiry, DNS records, broken links, scheduled tasks (cron jobs) and page speed through Lighthouse. Every plan has the same features, so the price depends only on the number of sites, starting at $17 a month for two.

It's the tool I usually recommend for Laravel apps with paying customers, because it catches the quiet failures too: a domain about to lapse, or a cron job that stopped running last Tuesday. Skip it if you have one small site and only need to know when it's down. A free monitor will do.

4. Uptime Kuma: free, if you're happy to run it yourself

Uptime Kuma is an open source, MIT-licensed monitor you install on your own server, usually with Docker. It can check as often as every 20 seconds, supports status pages and sends alerts through email, Slack and more than 90 other services. The software is free. The server and the time to keep it patched are not.

Pick it if you already have someone who looks after servers and you want full control over your data, for example by hosting it in an EU data center. Skip it if nobody on your side owns that job. An unmaintained monitor is just one more thing that can fail silently. And it must run on a different server from the app it watches.

Error tracking: catch what uptime checks miss

An uptime check tells you whether the app responds. It won't tell you that checkout fails for customers using one particular card type, or that a page throws an error for one user in a hundred. That's what an error tracker is for. It captures each error the moment it happens, with what a developer needs to fix it: which page, which user, which line of code and what happened just before.

5. Sentry: the broad choice

Sentry supports most languages and frameworks, which makes it the obvious pick when your product has several parts, such as a Laravel backend and a React or Next.js frontend. The free plan is for one user and 5,000 errors a month. The Team plan is $26 a month billed annually, with unlimited users. Sentry can store your data in Frankfurt, but you choose the region when you create the organization and can't change it afterwards.

Pick it for mixed stacks or when a team needs to share the error queue. Skip it if your app is pure Laravel and you'd rather have a tool built specifically for it. Sentry does a lot, and it takes a little while to learn your way around.

6. Flare: built for Laravel

Flare is made by Spatie, the Belgian company behind Ray, which I use myself for debugging during development. It's built for Laravel and PHP but also catches errors in JavaScript, React and Vue, and it covers performance and logs as well as errors. Pricing starts at $9 a month for one project, one user and 10,000 errors. Unlimited projects and users need a team plan from $29 a month, and there's a 10-day free trial.

Pick it if your app runs on Laravel and you want a tool designed around that framework. Skip it if a large part of your product is written in something other than PHP and JavaScript. I compare the two in more depth, and explain where Ray fits, in Sentry vs Flare vs Ray.

Cron jobs and background work: the failures nobody sees

Most web apps do work in the background: sending emails, generating invoices, syncing with an accounting system, cleaning up at night. When one of those jobs stops, usually nothing visible happens. The app responds fine and no errors appear, because the code isn't running at all. You find out when a customer asks where their invoice went.

The fix is a dead man's switch: the job checks in every time it runs, and you get an alert when the check-in doesn't arrive.

7. Healthchecks.io: cron monitoring on a small budget

Healthchecks.io does one thing and keeps it simple. Your job calls a URL when it finishes, and if the call is late, you get an alert. The free plan covers 20 jobs. The Business plan covers 100 jobs plus a set of SMS and phone call credits for $20 a month. It's run from Latvia and the code is open source, so you can host it yourself if you prefer.

Pick it if your app has scheduled tasks and your uptime tool doesn't already watch them. Oh Dear and Sentry both include cron monitoring, so if you use either, you probably don't need Healthchecks.io on top.

Performance: when the app is up but slow

A slow app is harder to spot than a broken one. No alert fires, but users give up halfway through a form and support gets emails saying the system is "hanging". Here you need tools that show which pages, database queries and jobs are eating the time.

8. Laravel Nightwatch: Laravel's own monitoring

Nightwatch is Laravel's official hosted monitoring service. It records requests, database queries, jobs, mail, notifications, scheduled tasks and exceptions, and shows where the time goes. According to the Nightwatch pricing page, the free plan includes 300,000 events and Pro is $20 a month for 7.5 million. It has data centers in both the US and the EU, and you can set a spending cap so the bill can't run away from you.

Pick it if your app runs on Laravel and gets enough traffic that it's hard to tell where things slow down. Because Nightwatch also captures exceptions, it can replace a separate error tracker for many Laravel apps. Skip it if your product isn't built on Laravel, since that's the only framework it supports.

9. Laravel Pulse: a free overview inside your app

Pulse is a free, open source package from Laravel that adds a dashboard to your own app. It shows slow requests, slow queries and jobs, exceptions, queues, cache hits and server CPU and memory. The data stays in a database you control, so nothing is sent to a third party.

The catch is that Pulse is a dashboard, not an alerting system. Someone has to remember to look at it. Use it for a quick overview without another subscription, but never as your only monitoring. If the app goes down, Pulse goes down with it.

10. Google Search Console: speed as real users see it

The other nine tools measure the server and the code. Search Console shows how your public pages perform in real browsers. Its Core Web Vitals report is based on anonymized data from real Chrome users and covers how fast the main content appears (LCP), how quickly the page responds to clicks (INP) and whether the layout jumps around (CLS). It's free.

Use it for every public page: your homepage, landing pages and any shop. It can't see pages behind a login, and low-traffic sites often show no data at all. For the logged-in part of a web app, Nightwatch, Pulse or Flare will tell you more.

Where your monitoring data is stored

For teams in the EU, or selling to EU customers, this matters more than it first seems. Error reports and logs regularly contain names, email addresses and IP addresses, which means the tool vendor is processing personal data on your behalf. In practice you'll want a data processing agreement (DPA) with each vendor and a clear answer on where the data sits.

Here's what I found for the tools above:

• Sentry offers an EU region in Frankfurt, chosen once when you create the organization.
• Nightwatch runs data centers in both the US and the EU.
• Oh Dear keeps its data in Belgium, and Flare is built by Spatie, also based in Belgium.
• Better Stack is headquartered in Prague, and Healthchecks.io is run from Latvia.
• Uptime Kuma and Healthchecks.io can be self-hosted, so the data lives wherever you put it.

A European company doesn't automatically mean European data storage, so check each vendor's DPA and list of subprocessors before you sign up. This isn't legal advice. If your app handles health, financial or other sensitive data, run it past your DPO or a lawyer.

Three setups by budget

You don't need all ten. Here's how I'd typically put them together for three sizes of web app:

The free setup beats having nothing, but checks are slower and there's rarely room for more than one user. The middle column, roughly €20-45 a month depending on the exchange rate, is what I'd recommend most often for a small business with an app it depends on. That's a small number next to what a single day of downtime usually costs.

If all you have is a simple marketing site, you don't need a developer for this. Create a free monitor with UptimeRobot or Better Stack, put your own email in as the contact, and you're done in about fifteen minutes. Error tracking, job monitoring and performance monitoring do require code changes, and they pay off most when the person who sets them up also fixes what they find.

Next steps: decide who gets the alert

The tools are the easy part. The harder part is deciding who receives the alert, what they're expected to do and what happens outside business hours, especially if your developer works in a different time zone from your customers.

If your developer is expected to respond to alerts, put response times and responsibilities in writing. My checklist for a software maintenance agreement covers what that contract should include. Monitoring also goes hand in hand with a web app backup strategy: the alert tells you something is wrong, and the backup is what you restore from.

If you'd like one person to set up the monitoring and act on it when it fires, here's how I handle web app maintenance and ongoing development.

Frequently asked questions

How often should a web app's uptime be checked?+

Every minute is a sensible default for an app with paying customers, and every five minutes is usually fine for an internal tool or a simple site. Checking more often than once a minute rarely pays off for a small business, because it still takes time for someone to react. It's better to check from several locations, so a single network glitch doesn't trigger a false alarm.

Isn't my hosting provider already monitoring my app?+

Usually only the server, not your app. Your host can see whether the machine is running, but not whether login works, payments go through or a background job has stalled. Most hosts also won't alert you when your application fails. That's why you want your own outside monitoring, wherever the app is hosted.

What's the difference between monitoring and logging?+

Monitoring tells you something is wrong right now. Logging records what happened, so you can work out why afterwards. You need both: the alert says checkout is down, and the logs show the cause. Several tools on this list, including Flare and Nightwatch, now keep errors and logs in one place.

Do I need a public status page?+

Only if many customers rely on your app day to day. A status page shows whether the system is up and what you're doing about an incident, which saves customers from emailing or calling to ask. For an internal tool or an app with a handful of users, a direct email to the people affected is usually enough.