Logging New Added 15 October 2026

Python: --- Logging error --- TypeError: not all arguments converted

The logging module formats messages lazily with the % operator, and a call like logger.info("user", user_id) passes an argument with no %s to put it in. Logging deliberately does not raise: it prints this block to stderr and drops the message, so the program carries on and the log you wanted is simply missing. The same happens with f-string style {} placeholders, which logging does not understand.

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

# The traceback under 'Call stack:' shows the exact logging call

# Wrong: argument with no placeholder, or {} placeholders
# logger.info("user", user_id)
# logger.info("user {}", user_id)

# Right: %-style placeholders, formatted only if the level is enabled
logger.info("user %s logged in", user_id)

# Or format it yourself (always formats, even when filtered out)
logger.info(f"user {user_id} logged in")

# Make these errors fail loudly in tests
import logging; logging.raiseExceptions = True

# Pylint catches them before they run
pip install pylint && pylint --disable=all --enable=logging-too-many-args,logging-format-interpolation src/

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 18 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.