Logging New Added 19 September 2026

Python: logging.basicConfig() has no effect and nothing is logged

basicConfig only does anything when the root logger has no handlers yet, so it is a silent no operation if any import or framework configured logging first. The second trap is the level: the default is WARNING, so info() and debug() are dropped even when the handler is correct.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

import logging

# force=True replaces whatever another library already installed
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s %(message)s",
    force=True,
)

# Inspect the state rather than guessing which import won
root = logging.getLogger()
print(root.level, root.handlers)
print(logging.getLogger("myapp").getEffectiveLevel())

# Both the logger and its handler filter, so both levels have to allow the record
h = logging.StreamHandler()
h.setLevel(logging.DEBUG)
logging.getLogger("myapp").setLevel(logging.DEBUG)

# In libraries, add a null handler and configure nothing
logging.getLogger(__name__).addHandler(logging.NullHandler())

# Duplicate lines are the mirror image: a handler added on every call,
# or propagation sending records to the root as well
logging.getLogger("myapp").propagate = False

How to diagnose Logging errors

Logging failures are dangerous because they are silent: the application keeps running while its telemetry disappears. The recurring causes are buffer overflow under backpressure (the destination cannot keep up), permissions on log files or directories, and ingestion rate limits at the cloud provider. Monitoring the logging pipeline itself is the only reliable way to notice.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Check the collector's own logs first: Fluentd, Logstash and the CloudWatch agent all log their own failures, usually to a separate destination.
Look for backpressure metrics: buffer queue length, retry counts, and dropped-record counters. A full buffer means the destination, not the collector, is the bottleneck.
Verify write permissions and disk space on the buffer path. A full disk silently stops most collectors.
For cloud ingestion, check the API rate limit for the log group or stream and batch more aggressively rather than retrying harder.
Add a heartbeat log line and alert on its absence. This is the only way to detect a pipeline that has stopped without erroring.

Tools worth reaching for

collector self-logs
buffer/queue metrics
df -h
aws logs describe-log-streams
logger / fluent-cat for test events

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

docs.python.org docs.python.org

Related Logging errors

See all 12 Logging errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.