24 January 2026 · 4 min read
Three signals, wired early
Structured logs with a request identifier, distributed traces across service boundaries, and a handful of business metrics. This covers most incident investigations.
Consistent request identifiers threaded through every log line is the single highest-value practice.
Alert on symptoms, not causes
Alert on error rate, latency, and queue depth — things users feel. CPU alerts mostly produce noise.
Every alert should have a runbook link. An alert with no defined action should be a dashboard instead.
Practise the investigation
Run a game day where someone breaks something on a staging environment and the team investigates using only production tooling.
The gaps this exposes are the ones that will hurt during a real incident.
Where to go from here
If you are weighing observability for an upcoming project, the useful next step is usually a short scoping conversation rather than a longer article. Bring your constraints — budget, timeline, existing systems, and the team you already have — and the decision usually resolves itself in an hour.
We run these as a fixed-scope discovery session with a written recommendation at the end, including the cases where our advice is that you do not need us.
Working on something like this?
Send us the brief. We will tell you what we would build, what we would cut, and roughly what it costs.
Talk to us