Introduction

“TensorBoard not working” can mean several different failures: the page does not open, the UI opens but shows no data, the graphs are stale, or summaries never appear at all. The fastest way to debug it is to separate the problem into three layers: are event files being written, is TensorBoard reading the right log directory, and can your browser reach the server.

First Check That Logs Actually Exist

TensorBoard cannot display anything if your training code never wrote summary events. A minimal TensorFlow example looks like this:

1import tensorflow as tf
2import datetime
3
4logdir = "logs/" + datetime.datetime.now().strftime("%Y%m%d-%H%M%S")
5writer = tf.summary.create_file_writer(logdir)
6
7for step in range(5):
8    with writer.as_default():
9        tf.summary.scalar("loss", 1.0 / (step + 1), step=step)
10    writer.flush()
11
12print(logdir)

After running that, confirm event files are present under the printed directory. If the directory is empty, the problem is in your training code, not in TensorBoard itself.

Start TensorBoard With the Correct Log Directory

Point TensorBoard at the directory that contains the event files:

tensorboard --logdir logs

If you wrote events to a nested timestamped directory, using the parent directory is usually fine because TensorBoard will scan subdirectories.

A very common problem is starting TensorBoard in the wrong folder and assuming logs refers to the same place as your training script. Use absolute paths when in doubt:

tensorboard --logdir /full/path/to/project/logs

If the Page Does Not Open

By default TensorBoard binds to port 6006. If that port is busy, start it on another one:

tensorboard --logdir logs --port 6007

Then open:

http://localhost:6007

If you are on a remote machine, notebook server, container, or VM, localhost in your browser may not be the same machine where TensorBoard is running. In those cases you may need port forwarding or a bind like:

tensorboard --logdir logs --host 0.0.0.0

Use that only when the network setup requires it.

If TensorBoard Opens but Shows No Data

This usually means one of four things:

• the wrong log directory was provided
• summaries were never written
• the process has not flushed events yet
• the selected dashboard does not match the type of summary data

For example, the Scalars tab needs scalar summaries. A graph-only run will not show scalar charts.

If your training loop is still running, flush the writer periodically:

with writer.as_default():
    tf.summary.scalar("accuracy", 0.92, step=10)
writer.flush()

Without flushing, new data may not appear when you expect.

Version and Environment Issues

TensorBoard is usually happiest when installed in the same Python environment as TensorFlow and the training code that wrote the logs.

Useful checks:

python -m tensorboard.main --logdir logs
python -c "import tensorflow as tf; print(tf.__version__)"
python -c "import tensorboard; print(tensorboard.__version__)"

Running TensorBoard through python -m is a good way to avoid accidentally launching a different environment’s binary.

If the versions are wildly mismatched or the command resolves from the wrong environment, fix the installation before debugging the UI further.

Jupyter and Notebook Cases

Inside notebooks, people often expect TensorBoard magic to work immediately. The notebook kernel and the shell environment do not always point at the same interpreter, so %tensorboard may fail even when the command line version works.

A reliable notebook pattern is:

%load_ext tensorboard
%tensorboard --logdir logs

If that still does not work, verify that the notebook kernel can import the same TensorBoard package version as your training code.

Stale or Confusing Results

Sometimes TensorBoard is technically working, but the data looks wrong because old runs and new runs share the same log directory. A clean workflow is to give each run its own subdirectory:

logdir = "logs/run-001"

or timestamp them automatically as shown earlier. Reusing one directory for many unrelated experiments makes the UI harder to interpret and can look like TensorBoard is broken when it is really just mixing runs.

Common Pitfalls

The biggest pitfall is blaming TensorBoard when the training script never wrote event files. Check the filesystem first.

Another common issue is starting TensorBoard in one working directory and training in another, then passing a relative path that points to the wrong place.

People also often forget about flush(), especially in short scripts. The program finishes too quickly or the writer never flushes, so the UI appears empty.

Finally, remote environments add network confusion. If TensorBoard is inside Docker, a cloud VM, or a notebook server, localhost:6006 in your browser may not reach the actual process.

Summary

• First confirm that TensorFlow summary event files are actually being written.
• Start TensorBoard with the correct log directory, preferably using an absolute path when debugging.
• Check port, host binding, and remote-network setup if the page does not open.
• Use the same Python environment for TensorFlow, TensorBoard, and notebook kernels when possible.
• Separate runs into distinct log directories to avoid stale or misleading results.