How to Know When Your App Is Down (Before Your Users Tell You)

The worst way to find out your app is broken is an email from a user that starts "not sure if you know, but…" By then it's been broken for a while, other users hit it and silently left, and you're debugging with nothing but a vague description.

Knowing first doesn't take a monitoring team. For a small app, three layers cover almost everything, most have free tiers, and together they take an afternoon to set up.

Layer 1: uptime checks — "is it up?"

An uptime monitor is a service that visits your app every minute or so from somewhere else on the internet, and alerts you when it doesn't get a healthy response.

What to check:

Your homepage — the obvious one.
A health-check endpoint — a URL like /health that your app answers only if it's genuinely working. A good one checks that the app can reach its database, not just that the web server responds. A homepage can load from cache while the database is down.
Your API, if the frontend and backend are separate.
The SSL certificate — most uptime tools also warn you before it expires. Certificate renewal usually just works, and an expired certificate makes your whole site show a scary browser warning when it doesn't. (How Automatic SSL Works explains why renewals fail.)
Your domain registration — some tools also warn before the domain itself expires, which takes down everything at once.

How to set it up: there are many hosted uptime services with free tiers — UptimeRobot, Better Stack, and others. Add the URLs, and have alerts go somewhere you'll actually see: a push notification to your phone is better than an email you check twice a day.

Check from outside. An uptime check must run somewhere other than the server it's checking. A server can't report that it's down.

Layer 2: error tracking — "what broke?"

Uptime checks tell you the site is up. They don't tell you that checkout has been throwing an error for every user with an apostrophe in their name. Error tracking does.

An error-tracking service — Sentry is the best known; there are others — installs as a small library in your app. When your code throws an error, in the browser or on the server, it sends the details: the error message, the exact line, the stack trace, which browser, which page, and how many users hit it.

Why it's so valuable:

You find out about bugs that don't take the site down but quietly break one feature.
You get the actual error, not a user's description of it.
Errors are grouped, so you can see "this happened 340 times since yesterday's deploy" and fix what matters most.
If you work with an AI agent, the stack trace is exactly what it needs to fix the bug. Paste it in, or connect the error tracker to your agent directly. (Connecting MCP Servers to Claude Code covers that.)

One setting to get right: tag errors with the release or commit they came from. Then "did the last deploy break something?" becomes a question you can answer in seconds.

One thing to avoid: don't send personal data. Configure the tool to scrub passwords, tokens, and personal details from error reports.

Layer 3: logs — "what happened?"

Logs are the running commentary your app writes: requests received, jobs run, warnings, errors. When something odd happens, logs let you reconstruct the sequence.

Most hosts show your app's logs. What matters is:

You can search them. "Show me everything for user 4812 between 2pm and 3pm."
They're kept long enough. A day isn't enough to investigate something a user reports on Monday about Friday.
They're useful. Log the things you'll wish you had: important actions, external calls that fail, background jobs starting and finishing. Don't log passwords, tokens, or full payment details.

For a small app, your host's built-in logs are often enough. If they're not searchable or aren't kept long enough, a log service can collect them.

Layer 4 (optional): background jobs and scheduled tasks

Anything that runs on a schedule — a nightly email, a cleanup job, a backup — can fail silently for weeks, because nobody's watching when it runs. The fix is a heartbeat check: the job pings a URL each time it succeeds, and you get an alert if the ping doesn't arrive on time. Many uptime services offer this. Put one on your backups especially; a backup job that silently stopped is only discovered on the day you need it. More on jobs in Your App Needs Background Jobs.

Alerts you won't learn to ignore

The fastest way to make monitoring useless is to alert on everything. After a week of false alarms, you start ignoring them, and then you ignore the real one.

Alert on what users feel: the site is down, errors spiked, checkout failed, a job didn't run. Not "CPU was high for a minute."
Require a problem to persist. One failed check is often a network blip; two or three in a row is an outage. Most tools let you set this.
Separate urgent from informational. "Site down" goes to your phone. "New error type seen" can be a daily email.
Every alert should have an obvious first action. If you don't know what to do when it fires, it's not a useful alert yet.

A status page, when you have customers

Once you have paying users, a simple public status page — many uptime services include one — saves you answering the same "is it down?" email fifty times during an incident, and makes you look organised while you fix things.

The afternoon setup

Uptime checks on the homepage, a /health endpoint that tests the database, and the API
SSL and domain expiry warnings on
Alerts to your phone, requiring two or three consecutive failures
Error tracking installed on frontend and backend, tagged with release
Personal data scrubbed from error reports
Logs searchable and kept for at least a couple of weeks
Heartbeat checks on scheduled jobs, especially backups

None of this prevents problems. It means you hear about them in minutes instead of days — and when you do, you already know where to look.

EasySpawn handles the infrastructure layer for you — automatic SSL issuance and renewal, managed databases with daily backups, and a 99.9% uptime SLA — so your monitoring can focus on your app. See how it works or join the waitlist.