structlog is the production-ready logging solution for Python:
- Simple: Everything is about functions that take and return dictionaries – all hidden behind familiar APIs.
- Powerful: Functions and dictionaries aren’t just simple but also powerful. structlog leaves you in control.
- Fast: structlog is not hamstrung by designs of yore. Its flexibility comes not at the price of performance.
Thanks to its flexible design, you choose whether you want structlog to take care of the output of your log entries or whether you prefer to forward them to an existing logging system like the standard library's logging module.
The output format is just as flexible and structlog comes with support for JSON, logfmt, as well as pretty console output out-of-the-box:
Sponsors
structlog would not be possible without our amazing sponsors. Especially those generously supporting us at the The Organization tier and higher:
Please consider joining them to help make structlog’s maintenance more sustainable!
Introduction
structlog has been successfully used in production at every scale since 2013, while embracing cutting-edge technologies like asyncio, context variables, or type hints as they emerged. Its paradigms proved influential enough to help design structured logging packages across ecosystems.
Project Links
- Get Help (use the structlog tag on Stack Overflow)
- PyPI
- GitHub
- Documentation
- Changelog
- Third-party Extensions
structlog for Enterprise
Available as part of the Tidelift Subscription.
The maintainers of structlog and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source packages you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact packages you use.
Release Information
Removed
- Python 3.8 and 3.9 support.
Deprecated
- Support for better-exceptions is deprecated and will be removed within a year. Use our Rich integration or copy-paste the one line of code you need. #802
Added
-
Python 3.15 support. #813
-
structlog.dev.rich_monochrome_tracebackfor Rich-based monochrome exception rendering and add support for it throughoutstructlog.dev.ConsoleRendererwhen the user asks for no colors. #794 -
structlog.BytesLoggernow has anameattribute which allows you to use it with thestructlog.stdlib.add_logger_name()processor without using the standard library integration. #786 -
structlog.processors.CallsiteParameterAddernow supportsCallsiteParameter.QUAL_MODULEthat adds the qualified import name of the module of the callsite, or__main__if the module is the entry point. This is only available for structlog-originated events since the standard library has no equivalent (except for the convention of setting the logger's name to__name__). #812 -
structlog.stdlib.BoundLoggernow hasis_enabled_for()andget_effective_level()methods that are snake_case aliases for itsisEnabledFor()andgetEffectiveLevel()methods. This makes it more compatible with the nativestructlog.typing.FilteringBoundLogger, so you can swap configurations without changing your call sites. #818
Changed
structlog.dev.ConsoleRendererdoes not warn anymore when theexceptionkey has a rendered value despite having a fancy formatter configured. #790
Fixed
-
structlog.BytesLogger,structlog.PrintLogger, andstructlog.WriteLoggernow hold weak references to the files they use for output. This prevents their leakage in long-running processes that open many logfiles, such as task executors that create a per-taskBytesLoggerorWriteLogger. #807 -
structlog.WriteLoggeris usable after unpickling. #787 -
structlog.processors.CallsiteParameterAddernow reports the calling thread's id and name for async log methods, instead of the thread from the executor pool that runs the underlying sync logger. #710 #805
Credits
structlog is written and maintained by Hynek Schlawack. The idea of bound loggers is inspired by previous work by Jean-Paul Calderone and David Reid.
The development is kindly supported by my employer Variomedia AG, structlog’s Tidelift subscribers, and all my amazing GitHub Sponsors.
The logs-loving beaver logo has been contributed by Lynn Root.
1 maintainer
Release files for structlog 26.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| structlog-26.1.0.tar.gz | 1.5 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| structlog-26.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 1.5 MB
Release files / structlog-26.1.0.tar.gz
| Download URL | structlog-26.1.0.tar.gz |
|---|---|
| Size | 1.5 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f63a716cbd1b1291cf7661de7794b455acfa4c43c5bcf1630e6ad5ddc1adb3b7
|
|
BLAKE2b-256 checksum How to use checksums |
5e89b4a0bcfdf4f71a3dea31379f095929613d7e4528a0996bca6aa964cd0dca
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jun 6, 2026.
Transparency logRelease files / structlog-26.1.0-py3-none-any.whl
| Download URL | structlog-26.1.0-py3-none-any.whl |
|---|---|
| Size | 73.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e081a26d6c373e6d201eca24eede26d8ffab07f88f477822e679183428d3d91e
|
|
BLAKE2b-256 checksum How to use checksums |
a918489c97b834dfff9cf2fc2507cede4bcd4b11e67f84bc462acd1992496f86
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jun 6, 2026.
Transparency log
