logr
logr is a lightweight logging interface for Go that decouples application code from specific logging implementations. Libraries and applications write logs against a simple Logger API, while actual log output is handled by pluggable LogSink implementations, enabling teams to switch logging backends without changing application code.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | go-logr/logr |
| Owner | go-logr |
| Primary language | Go |
| License | Apache-2.0 — OSI-approved |
| Stars | 1.4k |
| Forks | 86 |
| Open issues | 14 |
| Latest release | v1.4.3 (2025-05-28) |
| Last updated | 2026-07-05 |
| Source | https://github.com/go-logr/logr |
What logr is
logr provides a minimal two-type logging API (Info and Error) with verbosity levels, structured key-value pairs, and helper-function call-depth tracking. It defines Logger (high-level) and LogSink (low-level) interfaces, supports interoperability with Go 1.21+ slog via FromSlogHandler/ToSlogHandler, and includes built-in adapters (funcr, testr) plus community implementations for zap, logrus, zerolog, and others.
Get the logr source
Clone the repository and explore it locally.
git clone https://github.com/go-logr/logr.gitcd logr# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Choose a LogSink implementation early (zap/zapr for performance, logrus/logrusr for familiarity, stdr for stdlib simplicity). Document the choice for team consistency.
- Pass logr.Logger through constructors or struct fields; avoid package-global loggers unless unavoidable. Use logr.WithName() and logr.WithValues() to add context without callback chains.
- Leverage logr.NewContext() and logr.FromContext() for context-aware logging in middleware or handlers; ensure structured key-value pairs are stable across call chains.
- If integrating with slog-based code, use FromSlogHandler/ToSlogHandler; note that slog.Handler and logr.Sink cannot be implemented by the same type due to parameter conflicts.
- Test logging via testr (JSON output) or funcr (function-based) adapters; avoid asserting on log output in unit tests unless integration-level validation is required.
When to avoid it — and what to weigh
- Simple stdout/stderr Suffices — If your application needs only basic print-to-console logging with no structure, slog (Go stdlib) or even fmt.Printf may be simpler. logr adds abstraction overhead for trivial use cases.
- Heavyweight Log Aggregation Required Early — logr is an interface, not an aggregation platform. If you need built-in correlation IDs, sampling, or real-time alerting in the core library, use a full logging framework directly.
- Very High-Volume, Ultra-Low-Latency Logging — logr's abstraction and interface indirection may introduce measurable overhead in microsecond-level latency-critical paths. For extremely high throughput, benchmark against direct implementations.
- Static Typing of Log Levels Required — logr uses numeric verbosity (V method) and only Info/Error variants. If your team mandates named levels (DEBUG, WARN, TRACE) with compile-time guarantees, slog or a dedicated framework may fit better.
License & commercial use
logr is licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license. Commercial use, modification, and distribution are allowed under the standard Apache 2.0 terms.
Apache-2.0 explicitly permits commercial use without additional licensing. No trademark or patent clauses restrict business deployment. However, standard Apache indemnification clauses apply; review your internal IP policy if bundling with proprietary code.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Strong |
| License clarity | Clear |
| Deployment complexity | Low |
| DEV.co fit | Strong |
| Assessment confidence | High |
logr is a thin abstraction layer with minimal attack surface. No authentication, encryption, or network I/O in the core library. Security posture depends entirely on the LogSink implementation chosen (e.g., ensure your zap/logrus adapter does not leak secrets in structured fields). Validate that sensitive data is not logged in production or is redacted at the sink level.
Alternatives to consider
slog (Go 1.21+ stdlib)
Native Go logging interface; no third-party dependency. Lacks logr features (Marshaler, WithName, context passing, V-based verbosity), but simpler if you don't need library abstraction or are greenfield-only.
hashicorp/hclog
Full-featured structured logging library with built-in implementations. Less abstraction overhead, but couples libraries to hclog if used directly. Better if you control all logging code.
go.uber.org/zap
High-performance structured logging with typed fields. Can be used directly (no interface layer) or wrapped via zapr. Better for latency-critical or extremely high-volume applications.
Build on logr with DEV.co software developers
logr is production-ready and widely adopted in Kubernetes ecosystems. Review our implementation guide and choose your LogSink backend.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
logr FAQ
Should I use logr in a new Go project?
Can I mix logr and slog in the same codebase?
What is V() and how do I use verbosity levels?
Which LogSink should I pick for my app?
Work with a software development agency
Adopting logr is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source observability software in production.
Ready to decouple your logging?
logr is production-ready and widely adopted in Kubernetes ecosystems. Review our implementation guide and choose your LogSink backend.