Monitoring vs observability for small teams: alerts that matter

Monitoring vs observability isn't really a competition — they answer different questions. Monitoring watches for failure modes you already thought of and alerts when one happens — disk full, service down, error rate spiking. Observability is the wider ability to ask new questions about what a system is doing from the data it already produces, which matters most for the failure you didn't predict. Small teams need monitoring first, almost always; observability is what you add once monitoring alone stops being enough to explain what broke.

This post covers what to watch, how to avoid drowning in alerts nobody reads, and a starter stack built entirely from fair, open-source tools. For the wider practice of responding once an alert fires, see monitoring and incident response and our companion guide on DevOps as a service.

Monitoring vs observability: what's actually different#

A monitoring dashboard answers questions you defined in advance — is CPU over 80%, is the error rate above 1%. Observability is what lets you answer a question you didn't think to ask beforehand, such as "why do only logged-in users on mobile see this error" — by slicing the same underlying data in a new way rather than waiting for someone to build that exact dashboard. In practice the two overlap heavily and use the same telemetry; the difference is more about whether your tools stop at "alert me" or let you keep digging.

The four golden signals: what to watch on any user-facing service#

Google's Site Reliability Engineering book proposes four signals that cover most user-facing services well enough to start:

• Latency — how long requests take, tracked separately for successful and failed requests (a fast error and a slow success both hide real problems if you only average them together).
• Traffic — demand on the system, such as requests per second.
• Errors — the rate of failed requests, including ones that return a "successful" status but the wrong content.
• Saturation — how full the service is, watching the most constrained resource, because many systems degrade before they hit 100% utilisation.

If you only instrument four things, these are the four.

RED and USE: two checklists for two different layers#

Two narrower frameworks make the golden signals concrete for specific layers:

• RED (Rate, Errors, Duration), created by Tom Wilkie for monitoring microservices: requests per second, how many fail, and how long they take. It fits anything request-driven — your API, your web app, a background job queue.
• USE (Utilisation, Saturation, Errors), from performance engineer Brendan Gregg: for every hardware or infrastructure resource, check how busy it is, how much work is queued waiting for it, and how many errors it's logged. It fits CPU, disk, memory and network — the things RED doesn't cover well.

Use RED for your services and USE for the infrastructure underneath them, and between the two you've covered nearly everything worth watching.

Logs, metrics and traces: three kinds of telemetry, one picture#

• Metrics are numbers over time — request counts, latency, CPU percentage. Cheap to store, fast to query, best for "is something wrong right now" and for driving alerts.
• Logs are discrete, timestamped events — an error message, a request line, an audit entry. Best for "what exactly happened" once you know roughly when.
• Traces follow a single request as it crosses multiple services, showing where time went across that chain. They earn their cost once a request genuinely crosses several services; a single monolith usually doesn't need them yet.

OpenTelemetry has become the vendor-neutral way to generate and export all three from your own code, so you're not locked into one monitoring vendor's instrumentation format.

Alert fatigue is a design problem, not a tooling problem#

The SRE book's clearest advice on alerting is to separate symptoms ("the checkout page is returning errors") from causes ("one of six database replicas is behind"). Page a human for symptoms users would actually notice; route probable causes and anything not urgent to a ticket queue or a dashboard instead. This is also why black-box monitoring — checking a system from the outside, the way a user would experience it — is generally the better trigger for paging someone, compared with white-box monitoring of internal state, which is better for diagnosis after you're already looking.

What makes an alert actionable#

Before adding an alert, it's worth being able to answer yes to each of these:

• Is this urgent enough to interrupt someone right now, rather than wait for the morning?
• Is there something a human can actually do about it immediately?
• Does it indicate real impact — to a user, to data, or to the business — not just an internal metric moving?
• Does it link to a runbook, or at least a clear first step, so the person paged isn't starting from zero?
• Has this rule fired usefully in the last few months, or has everyone learned to dismiss it?

An alert that fails the first three shouldn't page anyone. An alert that fails the last one should be deleted or retuned, not left in place "just in case."

How this scales down for a team of one or two#

None of the above requires a dedicated observability engineer. A team of one or two can run this well by keeping the alert count deliberately small: start with the "is it up" check and one or two golden-signal alerts (error rate and latency), and add more only when a real incident shows you a gap — not speculatively. The failure mode for small teams is rarely "too little monitoring installed"; it's a dashboard nobody looks at and an alert channel everyone has muted. A handful of alerts that people trust beats a comprehensive set they've learned to ignore.

Don't forget the simplest check: is it up at all?#

Before golden signals, RED, USE or any of it, confirm your site or API is reachable from outside your own infrastructure. An external uptime check catches DNS problems, expired certificates and total outages that internal metrics can miss entirely, because your monitoring stack can be down for the same reason your site is. This is the cheapest, highest-value check you can add today, and it's also the raw data behind the uptime percentage in any SLA — see 99.9% vs 99.99% uptime for how that number gets calculated and what it's actually worth.

A fair open-source starter stack#

None of these require an enterprise contract to start, and none of them are ours to sell — they're genuinely useful defaults for a small team:

Start with Uptime Kuma and Prometheus plus Grafana — that alone covers "is it up" and the four golden signals. Add Loki when grepping log files gets painful, and OpenTelemetry tracing only once you have more than one service in the request path.

A starter alert table#

What to do next#

If you have no external uptime check today, that's the first gap to close — it takes under an hour with a free tool like Uptime Kuma. Once the basics are in place, see how we run monitoring and incident response for clients, and pair alerting with the response side of the problem in incident response for web apps.