Observability 101: Logs, Metrics and Traces for Teams Who Don't Have an SRE

Observability tooling vendors sell to teams with a platform engineering org and a six-figure tooling budget, and most growing SaaS teams do not have either. That does not mean observability is out of reach — it means the goal is a smaller, sharper version: enough visibility to answer "is it broken, where, and since when" within minutes, without the full enterprise toolchain.

The three signals, and the minimum that matters

• Logs — structured (not free-text) and centralized from day one; unstructured logs across a dozen servers are effectively unsearchable when you need them most.
• Metrics — a small set of business-relevant numbers (error rate, request latency, queue depth) on a dashboard the whole team actually looks at, not fifty vanity graphs nobody checks.
• Traces — one distributed trace per request across services, even a basic one, turns "something in the pipeline is slow" into "this specific downstream call is slow" in seconds instead of hours.

Teams often invest heavily in dashboards before they invest in structured logging, and it is backwards — a dashboard tells you something is wrong; structured, searchable logs tell you what and why. Fix the logging foundation first.

Alert on symptoms, not on everything you can measure

The fastest way to make an on-call rotation ignore alerts entirely is to page for every metric that can be measured. Alert on user-facing symptoms — elevated error rate, latency past a real threshold, a queue that is backing up — and treat everything else as a dashboard to check during investigation, not a page that wakes someone up. Alert fatigue is a self-inflicted reliability problem, and it is one of the most common we find auditing a client's existing setup.