Production monitoring for small apps: the minimum that lets you sleep

A small app in production needs four instruments, and the order matters. An external uptime check that visits a real URL every few minutes tells you the whole thing is down. Error tracking tells you the app is up and wrong. Logs that survive restarts tell you why. Alert routing decides who finds out, on which channel, at which hour. Everything beyond those four, dashboards, traces and the rest of the APM aisle, can wait, and for most small apps it can wait forever.

Rung one: uptime checks

An uptime monitor is a service elsewhere on the internet that requests a URL on an interval and alerts you when the answer stops being a healthy response. It catches the failures that take everything: the crashed process, the expired certificate, the deploy that broke the boot sequence, the whole-provider outage. It sees nothing else, which is fine, because nothing else is happening while the site is down.

Two details separate a useful check from a decorative one. Point it at a URL that exercises the real stack, a page that touches the database, since a cached homepage can return healthy while everything behind it is broken. And run it from outside your infrastructure, because a monitor inside the same provider shares its outages and stays green at precisely the moment you need it to speak up.

Setup is minutes, and every established provider in the category has a free tier a small app fits inside.

Rung two: error tracking

Uptime checks cannot see a checkout that fails for one user in ten, or an API returning errors while its status page glows. Error tracking can: it captures exceptions with the stack, the route, the user affected, and, when you tag releases, the deploy that introduced the problem. Tagging releases is the habit to build early. Errors annotated with release versions turn "something is wrong" into "this started with Thursday's deploy", which is most of the diagnosis done.

The setup is a client library and one environment variable, so it rides on the variables work the deploy already required.

Rung three: logs that survive restarts

The first production incident begins with a question about what the process said before it died. If the answer is "the terminal was closed", the investigation starts with archaeology. Logs need to live where a restart, a redeploy or a replaced container cannot delete them, and they need to be searchable without SSH, because you will read them on a phone.

This is partly a hosting requirement: the platform's logs should persist through restarts and be searchable in its panel. Where the platform's retention is thin, shipping logs to a hosted log service is the standard answer, and the free tiers in that category hold a small app's volume comfortably.

Rung four: alerting that respects your sleep

The instruments produce signals; routing decides whether those signals help you or train you to ignore them. The workable pattern for a small team: one channel that interrupts your phone, reserved for the site being down and error rates spiking, and a second channel, a daily digest, for everything else. Deduplicate, so one incident is one notification with a count attached, not forty messages. And hold the line on severity: if a 3am alert does not mean "act now", it gets muted by the second week, and the alert that did mean it gets slept through.

The test of the whole ladder is to take the app down on purpose, outside business hours, and watch what happens. One clear notification on the phone and the ladder works. Twelve notifications, or silence, and the routing needs fixing before you need it for real.

One more habit belongs at this rung: watch the watcher. Uptime services have outages too, and a monitor that quietly stopped checking looks identical to a monitor with nothing to report. A second, cheap check from a different provider, aimed at the same URL or at the first monitor's status page, catches the case where the thing that failed is the monitoring itself.

The weekly minute

With the ladder standing, running it is mostly reading. Once a week, scan the error digest for trends hiding under the alert threshold: the endpoint that fails a few times a day, the page nobody reported because users gave up quietly. That minute is where small apps get better, and it catches trends the alerts will never mention.

The dashboard mistake

The common miss is building the dashboard wall first. Graphs are pleasant and nobody watches them. Incidents arrive as notifications or as user complaints, and by the time someone opens a dashboard, the alert that mattered has usually fired, or failed to. Dashboards earn their place when you notice yourself looking up the same number by hand every week. Until one does, alerts carry the load.

What this costs

For many small apps, nothing: every rung has established providers with free tiers sized for exactly this scale, and a solo operator can stand the full ladder in an afternoon. The habit belongs to the launch rather than the backlog. Step six of putting an AI-built app into production is logs that survive the crash, and the ladder grows from there.