Uptime monitoring and error tracking for a small app
A simple monitoring setup for a small app: uptime checks that catch real outages, error tracking with readable stack traces, logs, alerts and free tiers.
Leer en español →
A small app needs two kinds of monitoring: an uptime monitor that checks your site and API from outside every few minutes and alerts you when they stop answering correctly, and an error tracker inside the code that records every crash with the line that caused it. Together they tell you that something broke, and where, before customers write in. For most small apps the free tiers of common tools are enough to start.
This guide explains what each layer catches, what to point your monitors at, how to set up error tracking so its reports are readable, and how to keep alerts useful instead of noisy.
What should a small app monitor?
Think in three layers.
| Layer | What it answers | Examples |
|---|---|---|
| Uptime checks | "Is the app reachable and showing the right thing?" | A service that requests your URLs every few minutes from outside |
| Error tracking | "What failed in the code, for whom, on which line?" | An SDK in your front end and functions that reports exceptions |
| Logs | "What exactly happened around that time?" | Your host's function logs and your database provider's logs |
Uptime checks find outages. Error tracking finds the bugs that only some users hit, which uptime checks never see because the home page loads fine.
What should my uptime checks point at?
A single check on the home page is the most common setup, and the weakest. Single-page apps return a 200 status for the page shell even when the data behind it is gone, so "200 OK" can mean "blank screen". Add checks that prove the app works:
- The home page, with a keyword check. Most uptime tools can look for a word on the page. Pick text that only appears when the page rendered properly, not text from an error page.
- A health endpoint that touches the database. A tiny server function that runs one cheap query and returns 200 if it worked, 503 if not. Return only a status, never data.
- Your API or main Edge Function, if the front end depends on it.
- Certificate and domain expiry. Many uptime tools can warn you before your SSL certificate or domain registration runs out.
Webhooks are the exception. An uptime check can't tell you whether Stripe's webhook is being processed. For those, check the delivery log in Stripe's dashboard regularly, or write a function that alerts you when expected events stop arriving. Our guide on paid users not getting access shows why that matters.
How often should checks run?
Every five minutes is fine for most small apps. UptimeRobot's free plan, for example, offers 50 monitors at 5-minute intervals and describes itself as "good for hobby and non-profit projects"; its paid Solo plan checks every 60 seconds from $12 a month on annual billing. Faster checks matter only when a few minutes of downtime is truly expensive.
How do I set up error tracking that's actually useful?
Sentry is a common choice, and its free Developer plan covers 5,000 errors a month for one user; the Team plan starts at $29 a month with 50,000 errors and unlimited users, per Sentry's pricing page. Other tools work the same way. Whatever you pick, four settings decide whether the reports help:
- Install it in the front end and in server functions. Front-end errors and backend errors are different populations; you want both.
- Upload source maps. Without them, stack traces point to minified code like
index-a1b2c3.js:1:48213. With them, you see the real file and line. Most tools have a build plugin for Vite and Next.js that uploads them during the build. - Tag the environment and release. Set the environment from your host's variable (on Vercel,
VERCEL_ENV) so preview errors don't mix with production ones, and tag each deploy so you can see which release introduced a bug. - Keep personal data out. Don't attach full request bodies, passwords or tokens. Sentry's JavaScript SDK doesn't send default personal data unless you enable
sendDefaultPii; leave it off unless you've decided otherwise.
Once it's running, attach the user's ID (not their email) to errors when they're logged in. That lets you answer "how many people hit this?" without storing more than you need.
Where do I find logs when something breaks?
- Your host. Vercel and Netlify show function logs per deployment. Look for the timestamp of the error your tracker reported.
- Your database provider. Supabase's dashboard has logs for the API, auth, storage and Edge Functions. Auth logs are where failed sign-ins and email sending errors show up.
- Retention is limited. Log history depends on your plan, often only days. If you need longer, forward logs to a dedicated service.
How do I keep alerts from becoming noise?
- Alert on two failures in a row, not one. A single failed check is often a blip.
- Send outage alerts somewhere you'll see them (phone push or SMS for downtime, email for everything else).
- Group errors by issue and alert on new issues or sudden spikes, not every occurrence.
- Review once a week. Fifteen minutes going through the top errors catches slow-burning problems.
- Check providers first. When an alert fires, look at your host's and database provider's status pages before you start debugging your own code.
What does a minimal setup look like?
- One uptime monitor with a keyword check on the home page.
- One on a health endpoint that queries the database.
- Error tracking in the front end and functions, with source maps and the environment tag.
- Alerts to your phone for downtime, email for new errors.
- A short note listing where each log lives and who gets alerts.
That can be done in an afternoon and costs nothing on free tiers.
Quick answers
Is a 200 status enough to know my app is up? No. Single-page apps can return 200 while showing an error or a blank screen. Use a keyword check and a database health check.
Will monitoring slow my app down? Error tracking adds a small script to the front end; uptime checks run from outside and don't touch your code. The effect on a typical app is negligible.
Do I need monitoring before launch? Set it up just before launch, not after the first outage. It's the only way to know about problems users don't report.
My app went blank and the monitor said everything was fine. Why? It was probably only checking the status code. Our guide to a blank white screen in a Lovable app covers the usual causes.
Want someone watching your app?
Monitoring only helps if someone acts on the alerts. Our maintenance and support plans (Care and Care Plus) include ongoing fixes and monitoring; details are on the pricing page. You can also run the free health check for a quick outside view of your app today.
