Monitoring and Observability Basics
Nobody sets out to fly blind in production. It just happens gradually: a few console logs here, a health check there, and then one day something breaks and the honest answer to ‘how would we have known’ is ‘a user told us.’ Monitoring and observability are the practice of closing that gap — not by buying a big platform on day one, but by deciding what you actually need to see.
This guide covers the three signals worth knowing by name, what’s worth alerting on before anything else, and a setup that’s genuinely minimal — the kind you can run before you’re big enough to justify a dedicated observability tool.
Logs, metrics and traces, in plain English
Logs are a record of discrete events — a request came in, a job failed, a user logged in — each with its own timestamp and detail. They’re the easiest signal to start with because most frameworks emit them for free, and they’re the best tool for answering ‘what exactly happened right before this broke.’
Metrics are numbers over time — request count, error rate, memory used — sampled at intervals rather than logged per event. They’re what makes a dashboard possible and what a good alert is usually built on, because a metric can tell you a trend is wrong before a human reads a single log line.
Traces follow one request as it moves through multiple services, showing where the time actually went. They matter far more once a system is more than one service; for a single application talking to a database, logs and metrics usually answer most questions traces would.
The four signals worth watching first
Google’s Site Reliability Engineering book narrows monitoring down to four golden signals, and they’re a genuinely good starting checklist for a small team deciding what to watch: latency (how long requests take), traffic (how much demand the system is under), errors (the rate of requests failing) and saturation (how full the system is — CPU, memory, connection pools, disk).
The reason these four matter more than a dashboard full of everything available is that they map directly to what a user experiences. A user doesn’t feel your CPU usage; they feel a slow page or a failed request. Watch the four signals first, and add anything more specific only once one of them tells you where to look.
Avoid alert fatigue: alert on symptoms, not causes
The fastest way to make monitoring worthless is to alert on everything that could theoretically be a problem. A team paged for every warning-level log line stops reading pages carefully within a couple of weeks — that’s alert fatigue, and once it sets in, the alert that actually matters gets the same shrug as the ones that didn’t.
The fix is alerting on symptoms a user would notice — elevated error rate, high latency, a service being down — rather than every possible internal cause. A single disk filling up on one of three replicas is a cause worth investigating during business hours; it’s not a symptom worth waking someone up for unless it’s actually affecting requests.
A minimum viable setup, before buying anything
You don’t need a dedicated observability platform to start. Most hosting platforms and frameworks ship basic request logging and uptime checks for free, and that alone catches the majority of what actually goes wrong for a small application: the service being down, and error rates spiking.
A workable starting point: structured logs (not just plain text, so they’re searchable later), one uptime check hitting a real endpoint (not just a static health page), and one alert each on error rate and response time against thresholds that reflect what your users actually tolerate. OpenTelemetry is worth knowing about even at this stage — it’s a vendor-neutral standard for emitting all three signal types, so instrumenting against it now means you’re not locked into whichever tool you pick first.
Frequently asked questions
What’s the actual difference between monitoring and observability?
Monitoring is watching known signals for known problems — a dashboard, a threshold, an alert. Observability is having enough detail in your system’s output that you can answer a question you didn’t think to ask in advance, by digging through logs, metrics and traces together. Small teams need monitoring first; observability tends to matter more as systems get more distributed.
Does a small app need distributed tracing?
Usually not yet. Tracing earns its cost once a request routinely crosses multiple services and a slow request could be slow in any one of them. A single application talking to one database gets more value, faster, from good logs and a couple of latency metrics.
What should the very first alert be?
Uptime — a check that hits a real, meaningful endpoint (not just a static page) and pages you if it stops responding. It’s the cheapest signal to set up and it catches the failure mode that hurts most: the app being down and nobody knowing.
Are free tiers of monitoring tools enough for a small project?
Often, yes, for the first year or two of a project’s life. Most platforms’ free or hosting-included tiers cover uptime checks and basic request logging, which handles the two failure modes that hit small apps most: downtime and error spikes. Upgrade when you outgrow the retention window or need more than a couple of alert rules.
What is alert fatigue, exactly?
The state a team reaches after being paged too often for things that didn’t need immediate action, to the point that alerts stop getting the attention they deserve — including the one time it’s real. It’s avoided by keeping alerts tied to symptoms a user would notice, not every internal fluctuation.
Explore the full desk on the home page →
Sources: Google SRE Book — Monitoring Distributed Systems · OpenTelemetry — What Is OpenTelemetry? — all accessed 4 August 2026.
One concierge, many modes
Learn it, apply it, go further — this page, your way.
Learn it (4)
Apply it (4)
Go further (4)
Terms used on this page
Tap any term for this site’s own definition — no search, no leaving the page.