Monitoring has a marketing problem. Search for it and you'll find dashboards with forty graphs, each more colorful than the last, all suggesting that serious people watch everything. They don't. Serious people watch four things and ignore the rest — because a metric nobody acts on is decoration, and decoration that pages you at night is worse than nothing.
Here's the four, in order.
1. Is it up?
The basics: a service outside your infrastructure that requests your app every few minutes and tells you when it fails. Free tiers check every five minutes, paid ones every minute. For most apps, start free.
Two details that separate useful from useless: check a page that actually touches your database (a static homepage can be "up" while everything behind it is down), and route the alert somewhere you'll genuinely see it. An alert to an inbox you check weekly is a diary, not an alarm.
2. Is it throwing errors?
Your app fails in small ways constantly — a crash here, an unhandled edge case there. Users rarely report these; they just leave. An error tracker (the free tiers are generous) collects every failure with enough context to understand it later.
Fair warning: the first week is humbling. Every app that's never had error tracking shows a backlog of failures nobody knew about. That's not a sign you built badly — it's what the tool is for. Skim the list weekly, fix what's frequent, mute what's harmless noise. Which brings us to—
3. Is money moving correctly?
The five-minute weekly ritual with the best return on time in this whole article: open your payment provider's dashboard and look at two lists — failed payments and failed webhook deliveries. Both should be boring. When they're not, you've caught a revenue leak days before a customer writes the email you don't want to get.
This check is embarrassingly simple, and we'd estimate most solo-run apps never do it. Be the exception.
4. What is this costing me right now?
Every usage-billed service in your stack needs a spending alert. Not because overruns are common — because the rare ones are spectacular. A runaway function, a scraped API, a bug calling an AI endpoint in a loop: these stories always end with a screenshot of an invoice, and the invoice is always from a service without an alert configured.
What you can safely ignore
Honestly? Most of the rest, at your stage. CPU graphs, memory curves, request latency percentiles, Lighthouse scores checked daily — these matter at scales you'll be delighted to reach someday. Watching them now is procrastination with a professional feel.
The test for any metric: "what would I do if this number turned bad?" No answer, no dashboard. It's the same discipline as a good alarm system — every alert should map to an action, or it trains you to ignore alerts, and then one day you ignore the real one.
The principle underneath
Here's the thing the tooling ads won't tell you: monitoring isn't a product you install. It's a habit with software attached. The uptime monitor only works if the alert reaches a human who reacts; the error list only works if someone skims it; the payment check only happens if it's in somebody's calendar.
In our handbook we call this "monitoring someone reads" — and it's exactly the part that's hard to sustain solo, not because it's difficult but because it's relentless. Weeks of nothing, then the one Tuesday that matters. If you'd rather that Tuesday be contractually our problem — with response times and credits when we miss — that's precisely the service. Either way: four numbers, watched by someone. That's monitoring. Everything else is dashboards.