TensorFlow
logging
bug fix
error messages
machine learning

Tensorflow suppresses logging messages bug

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

Introduction

When TensorFlow seems to hide warnings or diagnostic messages, the problem is often logging configuration rather than a real bug in model execution. TensorFlow writes logs from both Python and native C++ code, so muting one layer does not always affect the other, and setting the wrong level can hide information you actually need.

How TensorFlow Logging Is Split

TensorFlow emits messages from two main places. Python-side messages flow through tf.get_logger() and the standard logging module. Startup messages, device placement notices, and some backend warnings may come from the native runtime instead.

That separation explains why code like tf.get_logger().setLevel("ERROR") can reduce some output while low-level startup messages still appear. The reverse is also true: setting the native log threshold may quiet startup noise but leave Python warnings visible.

Controlling Native TensorFlow Logs

The most common switch is the TF_CPP_MIN_LOG_LEVEL environment variable. It must be set before TensorFlow is imported, otherwise the runtime has already initialized.

python
1import os
2
3os.environ["TF_CPP_MIN_LOG_LEVEL"] = "2"
4
5import tensorflow as tf
6
7print(tf.constant([1.0, 2.0, 3.0]))

Typical values are:

  • '0 for all messages'
  • '1 to hide informational messages'
  • '2 to hide informational messages and warnings'
  • '3 to hide informational messages, warnings, and most errors'

Using 3 is usually too aggressive during development because it can mask problems that would have helped you debug an environment or model issue.

Controlling Python-Side Logs

After import, you can tune TensorFlow’s Python logger like any other logger. This is useful when training output is buried under repeated warnings from your own code or from TensorFlow wrappers.

python
1import logging
2import tensorflow as tf
3
4logger = tf.get_logger()
5logger.setLevel(logging.ERROR)
6
7for handler in logger.handlers:
8    handler.setLevel(logging.ERROR)
9
10model = tf.keras.Sequential([
11    tf.keras.layers.Input(shape=(4,)),
12    tf.keras.layers.Dense(8, activation="relu"),
13    tf.keras.layers.Dense(1),
14])
15
16model.compile(optimizer="adam", loss="mse")
17print("logger configured")

This does not change the semantics of training. It only changes what reaches the console.

A Practical Debugging Pattern

If you suspect TensorFlow is suppressing output unexpectedly, start from the least restrictive configuration and tighten it step by step. That makes it much easier to see which layer is muting the message.

python
1import os
2import logging
3
4os.environ["TF_CPP_MIN_LOG_LEVEL"] = "0"
5
6import tensorflow as tf
7
8logger = tf.get_logger()
9logger.setLevel(logging.INFO)
10
11print("TensorFlow version:", tf.__version__)
12logger.info("Python-side TensorFlow logging is active")

If the custom logger.info line appears but native startup messages do not, your native log threshold is the place to investigate. If neither appears, a notebook configuration, wrapper script, or external logging policy may be swallowing stdout or stderr.

Why This Looks Like a Bug

The confusion usually comes from import order and execution environments. In notebooks, cells may import TensorFlow earlier than you realize, so later attempts to set TF_CPP_MIN_LOG_LEVEL do nothing. In larger applications, another module may configure the root logger first. In test runners, output capture can make messages appear to vanish even though TensorFlow still emitted them.

It is also common to copy a snippet from an online answer that sets both the environment variable and the Python logger to the strictest possible setting. That often solves noisy output and then becomes a hidden cause of missing diagnostics weeks later.

Common Pitfalls

The first pitfall is setting TF_CPP_MIN_LOG_LEVEL after import tensorflow as tf. At that point the native runtime is already initialized, so the environment variable is too late.

Another mistake is treating tf.get_logger() as a complete solution. It only controls Python-side logging. Backend messages can still bypass it.

Be careful with level 3. It is tempting when you want a quiet console, but it can hide useful warnings and make environment problems much harder to trace.

Finally, remember that some messages are not from TensorFlow at all. CUDA, cuDNN, oneDNN, and notebook environments may have their own output behavior. If TensorFlow settings do not explain the missing message, inspect the surrounding stack rather than assuming the framework dropped it.

Summary

  • TensorFlow logging comes from both Python loggers and the native runtime.
  • Set TF_CPP_MIN_LOG_LEVEL before importing TensorFlow or it will not affect native startup logs.
  • Use tf.get_logger() to control Python-side TensorFlow output after import.
  • Start with permissive logging when debugging, then reduce noise gradually.
  • What looks like a TensorFlow bug is often import order, notebook state, or another logger configuration issue.

Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

All Rights Reserved.