Using Tensorboard to monitor training real time and visualize the model architecture
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
TensorBoard is the standard tool for monitoring TensorFlow training runs, tracking metrics as they change, and inspecting model graphs. It is most useful when you treat training as an observable system rather than a blind batch job. The basic pattern is simple: write event logs during training, launch TensorBoard against those logs, and inspect metrics, graphs, and optional performance profiles in the browser.
Create a Clean Log Directory
TensorBoard reads event files from a log directory. A timestamped run directory keeps experiments isolated and makes comparisons easier.
Without per-run directories, unrelated training sessions can be merged into one confusing dashboard.
Log Training Metrics with the Keras Callback
For Keras workflows, the built-in TensorBoard callback is the fastest way to get live metric tracking.
This writes training and validation metrics to event files while the model is running.
Launch TensorBoard
Once the logs exist, point TensorBoard at the parent log directory.
In notebook environments, you can launch it inline:
After opening the URL, the Scalars tab shows how loss and accuracy evolve over time. This is the most common place to catch overfitting, stalled learning, or unstable training.
Visualize the Model Architecture
TensorBoard can display the model graph when graph logging is enabled. For many Keras models, write_graph=True is enough to populate the Graphs tab.
If you also want a static architecture image for documentation:
The TensorBoard graph is interactive and helpful for exploring the computational structure. The static diagram is more useful for docs and reviews.
Add Custom Scalars and Images
Built-in metrics are often not enough. TensorBoard also supports custom summaries for domain-specific values.
You can also log images:
This is useful for generated outputs, segmentation previews, or intermediate model artifacts that are hard to understand from scalar metrics alone.
Compare Multiple Runs
TensorBoard becomes much more powerful when you compare several experiments in one place. Keep separate run directories for different hyperparameters, architectures, or datasets.
Example structure:
- '
logs/lr-1e-3' - '
logs/lr-1e-4' - '
logs/wider-model'
When these live under the same parent directory, TensorBoard overlays them in the Scalars tab. That makes it much easier to compare convergence and stability.
Use Profiling Selectively
TensorBoard can also profile performance. That includes step timing, input pipeline behavior, and device utilization.
Profile only selected batches. Profiling everything adds overhead and can distort the behavior you are trying to measure.
Common Pitfalls
- Writing several unrelated experiments into one log directory.
- Expecting TensorBoard to show data when no event files are being written.
- Forgetting to flush custom summaries in long-running scripts.
- Treating the graph view as proof that the model is correct without validating shapes and outputs.
- Enabling expensive profiling on every batch.
Summary
- TensorBoard reads event logs written during training.
- The Keras TensorBoard callback is the easiest way to log live metrics.
- Separate run directories make comparisons meaningful.
- Graph and image views help with architecture inspection and debugging.
- Profiling and custom summaries make TensorBoard useful beyond simple loss curves.

