Introduction

This error means TensorBoard tried to listen on port 6006, but another process had already claimed it. Sometimes that process is an older TensorBoard instance. Other times it is an unrelated service, a notebook extension, or a background job you forgot was still running.

Confirm What Is Using the Port

Before killing anything, check which process owns the port.

On macOS or Linux:

lsof -i :6006

Or:

ss -ltnp | grep 6006

On Windows:

netstat -ano | findstr 6006

If the process is another TensorBoard session, you can stop that specific process by PID. That is better than blindly killing Python processes and taking down unrelated work.

Either Free the Port or Pick Another One

If the existing process should be stopped, terminate it and restart TensorBoard:

kill 12345
tensorboard --logdir ./logs

If the process should stay alive, run TensorBoard on a different port:

tensorboard --logdir ./logs --port 6007

This is often the fastest fix when you are comparing multiple runs or sharing one machine with other users.

Watch for Notebook and IDE Integrations

Jupyter, Colab, VS Code, and some experiment-tracking tools can launch TensorBoard for you. In those cases, you may not have started the conflicting process manually.

For example, notebook magic can start a background service:

%load_ext tensorboard
%tensorboard --logdir logs

If you later run the CLI version against the same default port, you can collide with the notebook-launched instance. The fix is still the same:

• stop the existing service
• or pick a different port

Remote Development Changes the Diagnosis

On remote machines, port 6006 can be busy locally, remotely, or inside an SSH tunnel. That means you may have two separate layers to check:

• the remote host where TensorBoard is running
• your local machine where the port is forwarded

A typical SSH tunnel looks like this:

ssh -L 16006:localhost:6006 user@remote-host

In that case, visiting http://localhost:16006 locally avoids competing for local port 6006.

If you want TensorBoard to listen on a non-loopback interface on the remote machine, specify the host explicitly:

tensorboard --logdir ./logs --host 0.0.0.0 --port 6006

Only do that on trusted networks or when access is otherwise controlled.

Use a Consistent Launch Pattern

The problem often repeats because launches are inconsistent. Pick one pattern and stick to it:

tensorboard --logdir ./logs --port 6006

Or, if you routinely run several experiments at once, assign ports intentionally:

tensorboard --logdir ./logs/run-a --port 6006
tensorboard --logdir ./logs/run-b --port 6007

That is cleaner than relying on whatever happens to be free.

Common Pitfalls

The biggest pitfall is assuming "port in use" means TensorBoard is broken. The message is usually accurate: another process already owns the port.

Another common mistake is killing every Python process on the machine. That can interrupt notebooks, training jobs, or unrelated services.

Notebook users often forget that a previous %tensorboard command may still be serving in the background. Remote users often forget that SSH port forwarding adds another place where collisions can happen.

Finally, do not expose TensorBoard with --host 0.0.0.0 unless you understand the network consequences.

Summary

• The error means some process already owns port 6006.
• Use lsof, ss, or netstat to identify the process first.
• Stop the existing process or launch TensorBoard with a different --port.
• Check notebook integrations and SSH tunnels if the conflict is not obvious.
• Use a repeatable launch pattern so repeated sessions do not collide by accident.