Monitoring for a team of three: the minimum that works
Small teams usually have one of two monitoring states: nothing at all, or a dashboard nobody looks at. Both mean the same thing — you learn about outages from a user. Here is the minimum that changes it in a day.
Four signals to start with
Not "collect every metric", but the four that answer "is the product working":
- External availability. A probe from another machine against the home page. If that fails, the rest of the metrics do not matter.
- Error rate. The share of 5xx responses. Not the absolute count, which grows with traffic.
- Latency at a percentile. p95, not the mean. The mean hides exactly the users who are having a bad time.
- Queue depth. If background jobs pile up, the enquiry email arrives tomorrow and technically everything is "working".
The external probe is the cheapest signal
An internal health check cannot see a dead nginx, an expired certificate or a DNS mistake. A probe from outside sees all three immediately. One request a minute, recording status code and duration, is enough.
Store a daily rollup rather than every probe: how many succeeded, how many were slow, how many failed. Then 90 days of history is 90 rows per service instead of hundreds of thousands, and the status page renders instantly.
An incident instead of a stream of alerts
The main reason people stop reading alerts: one outage generates forty messages. An incident model fixes it. When a service first stops responding, open an incident and send one notification. While it stays open, say nothing. When it recovers, send a second.
Two messages per event instead of forty. That is the difference between alerts people read and alerts that got their own filter folder.
An alert nobody acts on is worse than no alert: it creates the feeling of being in control.
Channels
Three of them, each with a job:
- A messenger (Telegram, Slack) — things you must see now. Incidents only.
- Email — things you can read in the evening: the weekly summary, delivery attempts that ran out, anomalies.
- A status page — what the customer reads instead of messaging you.
Metrics and errors
A Prometheus endpoint in the application is a dozen lines and gives you latency, errors and queue depth without any external service. Even if you do not run Prometheus yet, add the endpoint now: the day you need it will be the worst possible day to integrate anything.
Separately, collect errors with stack traces. Scrolling container logs is not a strategy, and grouping identical errors by frequency saves hours. Sentry or a compatible self-hosted alternative is a budget question, not an architectural one.
One rule
Every alert must answer "what should I do right now". If there is no answer, it is not an alert — it is a dashboard metric. Keeping that rule keeps monitoring alive longer than any tool will.
- An external probe sees what an internal health check cannot
- Daily rollups instead of every probe: 90 days of history in 90 rows
- The incident model: two messages per event instead of forty
- An alert with no answer to "what do I do now" is a metric, not an alert
The server itself, not necessarily on day one. The metrics endpoint is worth adding immediately: it is a dozen lines, and you will want it exactly when integrating anything is hardest.
Ninety days of daily rollups is enough for both a status page and an SLA conversation. Raw probe results are not worth keeping — they grow without limit and add nothing.
