Abstract
Your users are leaving before you know they had problems. A slow signup flow, a failing payment endpoint, or a broken onboarding step. By the time you hear about it from support tickets, you've already lost trust and revenue.
Most Go applications start with great intentions: fast iteration, clean code, and rapid shipping. But without the right observability foundations from day one, teams end up flying blind. Metrics live in one place, logs in another, and there's no way to connect a spike in error rates to actual user impact.
In this talk, I'll share hard-won lessons from building production systems at scale and show you how to instrument Go applications with user journeys at the center. You'll learn how to build a minimal, effective observability stack using OpenTelemetry, connect technical signals to business outcomes, and establish SLOs that Product and Engineering can co-own.
This is not a talk about adding more dashboards. This is about shipping fast with confidence.
What You'll Learn
1. Why observability is a Day 1 decision
- The cost of flying blind: churn, firefighting, and lost roadmap time
- How to measure user outcomes, not just server health
- The difference between good and great early-stage observability
2. Building the minimal observability stack in Go
- Instrumenting with OpenTelemetry: metrics, traces, and structured logs
- Choosing the right backends: Prometheus, Tempo, Loki (or managed alternatives)
- Connecting technical signals: from metric spike → trace → log → user impact
- Practical Go patterns: middleware, context propagation, and sampling strategies
3. Making SLOs about user journeys
- Defining SLIs/SLOs for core flows (signup, checkout, onboarding)
- Shared ownership between Product & Engineering
- Using error budgets to balance speed and reliability
- Release guardrails: detecting regressions in minutes, not hours
Target Audience
- Go developers at startups or scale-ups who want to build observability from the ground up
- Engineering leads balancing velocity with reliability
- Product Engineers who need to understand user impact, not just server metrics
- Anyone who has debugged production issues by guessing
Prerequisites: Basic Go experience. No prior observability knowledge required.
