Small products usually find out about outages from customers. A client calls to say the app is not loading, someone checks, and it turns out the disk filled up three hours ago. Monitoring exists so that you are the first to know, ideally before anyone notices.
The opposite failure is just as common: a monitoring system so noisy that everyone mutes the alerts, and then a real problem gets missed. For a product run by one person or a small team, the goal is a lean setup with few alerts, each of which means "act now".
This is the setup I use for products like NeonTask and Pro Clean+, which run as Dockerized services on Linux servers.
Layer 1: External uptime checks
Start from the outside, because that is what users see. An external service requests your public URLs every minute or so from several locations and alerts when they fail.
Check:
- The website home page.
- The API's health endpoint.
- The admin or web app login page.
- Any critical public page, such as a booking page.
Alert after a couple of consecutive failures, not one, to avoid alerts from a single network blip. Many hosted uptime services do this well, and some have generous free tiers. The important thing is that the checker runs somewhere other than your server, because a monitor on a dead server cannot tell you it is dead.
Layer 2: Health endpoints that mean something
A health endpoint that returns "OK" whenever the web process is running tells you little. A useful one checks the application's real dependencies:
- Can it reach the database and run a trivial query?
- Can it reach the cache or queue if one is used?
- Is disk space above a minimum?
Keep two endpoints: a light "liveness" check for container restarts, and a deeper "readiness" or status check for monitoring. Do not make the deep check too expensive, since it runs constantly, and do not expose sensitive details in its response.
Docker health checks on containers, combined with restart policies, handle many transient failures automatically. Monitoring then tells you when restarts happen repeatedly.
Layer 3: Error tracking
Uptime checks catch the site being down. They do not catch a button that throws an error for some users. Error tracking does: the backend, web app and mobile app report exceptions with stack traces, the request or screen involved, the release version and the device or browser.
Good practice:
- Tag every error with the release version, so you see immediately whether a deploy introduced it.
- Group similar errors and alert on new error types or sudden spikes, not every occurrence.
- Scrub personal data before it leaves the app.
- For mobile apps, crash reporting is essential, because you cannot read logs on users' phones.
Layer 4: Server and container metrics
Track the basics for each server:
- CPU and memory use.
- Disk usage and free space, per volume.
- Network traffic.
- Container status and restart counts.
- Database connections and slow queries, for the database.
A common lightweight stack is Prometheus with node exporter and cAdvisor, visualized in Grafana. Hosted options exist too. For a single server, even a simple agent that reports to a hosted dashboard is a big improvement over nothing.
Metrics are mainly for investigation and trends. Only a few should alert.
Layer 5: Logs you can search
When something goes wrong, you need to answer "what happened at 10:42?" quickly. That means:
- Structured logs (JSON) from your applications, with a request ID that follows a request through services.
- Log rotation, so Docker logs do not fill the disk. Configure size limits on the Docker logging driver.
- Ideally, central log storage you can search by time, service and request ID, such as Loki or a hosted log service.
Do not log passwords, tokens, card data or full personal records. Logs are often less protected than databases.
Layer 6: Business signals
Some of the most valuable checks are not technical. For a booking app: "no new bookings in the last N hours during working hours" is often the first sign something is broken in a way no technical check catches, such as an expired API key for SMS, a broken payment callback or a bad app release. Pick one or two key business events and alert when they stop.
Scheduled jobs deserve the same treatment. Use a "dead man's switch" style check: the job pings a URL when it finishes, and you get an alert if the ping does not arrive. This is the right way to watch backups. See Postgres backups that actually restore.
Alert rules that do not burn you out
Every alert should be:
- Actionable: there is something a person should do now.
- Urgent: it cannot wait until the morning. If it can, make it a daily report, not an alert.
- Clear: it says what is wrong, where, and links to the dashboard or runbook.
A small, sensible starting set:
- Public site or API down for more than a couple of minutes.
- Disk usage above a high threshold.
- A container restarting repeatedly.
- A spike in errors, or a new error type after a release.
- Backup or critical scheduled job missed.
- TLS certificate expiring soon, if renewal is not fully automatic.
- Business heartbeat stopped during working hours.
Everything else belongs on a dashboard you look at weekly.
Route alerts to a channel you will actually notice: a phone push or messaging app for urgent ones, email for daily summaries.
After every incident
Even on a tiny team, write a few lines after any real incident: what happened, how you found out, how long it took to fix and what would have caught it earlier. Then add the missing check or remove the noisy one. Monitoring improves through incidents, not through planning.
Common mistakes
- Monitoring only from inside the server.
- Alerts on CPU spikes that resolve by themselves.
- No log rotation, so the disk fills from logs.
- Error tracking set up but never read.
- One person receiving every alert with no backup.
- Backups unmonitored.
How it fits with the rest
Monitoring is one part of running a product properly, alongside a hardened server, repeatable deployments and real backups. If you are setting up a server, start with the hardening checklist, and see Docker Compose in production for the deployment side.
If you want help setting up monitoring that tells you about problems before your customers do, see my work and get in touch.