Go Logging

Opinionated, standard library first guidance for logging in Go. It pushes slog hard for new code, keeps messages static with structured key-value pairs, and hammers home the "log or return, not both" rule to stop error noise from cascading up the stack. The level semantics are sensible (Error means operator attention, not just "something went wrong"), and the request-scoped logger pattern via context is the right way to carry trace IDs through your handlers. If you're still using log.Printf or debating between zap and zerolog without profiling first, this will save you from yourself.

skills.sh installs: 1.1K
GitHub stars: 193
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add cxuu/golang-skills --skill go-logging --agent claude-code

Installs into .claude/skills of the current project.

Files

Go Logging

Compatibility: log/slog requires Go 1.21+; testing/slogtest requires Go 1.22+.

Resource Routing

references/LEVELS-AND-CONTEXT.md - Read when choosing log levels, deciding logger-in-context versus explicit parameters, or excluding sensitive fields.
references/LOGGING-PATTERNS.md - Read when configuring slog handlers, logging HTTP requests, testing handlers, or migrating from log.Printf.

Core Principle

Logs are for operators, not developers. Every log line should help someone diagnose a production issue. If it doesn't serve that purpose, it's noise.

Choosing a Logger

Normative: Use log/slog for new Go code.

slog is structured, leveled, and in the standard library (Go 1.21+). It covers the vast majority of production logging needs.

Which logger?
├─ New production code      → log/slog
├─ Trivial CLI / one-off    → log (standard)
└─ Measured perf bottleneck → zerolog or zap (benchmark first)

Do not introduce a third-party logging library unless profiling shows slog is a bottleneck in your hot path. When you do, keep the same structured key-value style.