clementtsang/bottom

Yet another cross-platform graphical process/system monitor.

13,104 stars Rust 10 components 7 connections

Cross-platform graphical process/system monitor for terminal (like htop/top)

Continuous system monitoring pipeline that collects metrics, stores them in time-series buffers, and renders real-time visualizations

Under the hood, the system uses 2 feedback loops, 3 data pools, 3 control points to manage its runtime behavior.

Structural Verdict

A 10-component dashboard with 7 connections. 164 files analyzed. Well-connected — clear data flow between components.

How Data Flows Through the System

Continuous system monitoring pipeline that collects metrics, stores them in time-series buffers, and renders real-time visualizations

System Collection — Harvest CPU, memory, network, disk, temperature, and process data using sysinfo and platform APIs
Data Ingestion — Store raw metrics in StoredData with time-series chunking and process hierarchy mapping
Data Processing — Apply filters, calculate rates, and prepare data for visualization
Widget Rendering — Render graphs, tables, and gauges using ratatui terminal UI framework
Event Handling — Process user input for navigation, process killing, and configuration changes

System Behavior

How the system actually operates at runtime — where data accumulates, what loops, what waits, and what controls what.

Data Pools

Time Series Buffer (in-memory)
Chunked storage for CPU, network, and other continuous metrics with automatic pruning

Process Data Store (in-memory)
Process hierarchy and metadata with parent-child mappings

Widget State Store (state-store)
UI state for all widgets including scroll positions and selections

Feedback Loops

Data Collection Loop (polling, reinforcing) — Trigger: Timer interval. Action: Collect system metrics and update data stores. Exit: Application shutdown.
UI Refresh Loop (polling, balancing) — Trigger: Render timer. Action: Update terminal display based on current data. Exit: Application shutdown.

Delays & Async Processing

Collection Interval (polling, ~configurable (default ~1s)) — Determines data freshness vs system load
Time Series Pruning (batch-window, ~30+ seconds) — Old data is removed to prevent memory growth

Control Points

Collection Rate (env-var) — Controls: How frequently system metrics are collected. Default: configurable
Feature Flags (feature-flag) — Controls: Which system monitors are enabled (battery, GPU, ZFS). Default: deploy features enabled by default
Widget Layout (runtime-toggle) — Controls: Widget positioning and display options. Default: customizable via config

Technology Stack

sysinfo (library)
System metrics collection

ratatui (framework)
Terminal UI rendering

clap (library)
Command-line argument parsing

crossterm (library)
Cross-platform terminal control

timeless (library)
Time-series data management

regex (library)
Process and data filtering

serde/toml_edit (library)
Configuration serialization

Key Components

start_bottom (function) — Main application loop that coordinates data collection, processing, and UI rendering src/lib.rs
StoredData (class) — Central data store holding time-series metrics, process data, and system stats src/app/data/store.rs
TimeSeriesData (class) — Chunked time-series storage for CPU, network, and other continuous metrics src/app/data/time_series.rs
ProcessData (class) — Process hierarchy mapping and process information storage src/app/data/process.rs
Data (class) — Raw system metrics collected from various sources (CPU, memory, disks, etc.) src/collection/mod.rs
AppWidgetStates (class) — UI state management for all widgets (scroll positions, selections, etc.) src/app/states.rs
BottomLayout (class) — Layout configuration and widget positioning system src/app/layout_manager.rs
Filter (class) — Regex-based filtering system for processes and other data entries src/app/filter.rs
BottomArgs (class) — Command-line argument parsing and configuration loading src/options/args.rs
widget modules (module) — Individual widget implementations (CPU graph, process table, memory display, etc.) src/widgets/

Configuration

codecov.yml (yaml)

coverage.status.project.default.target (string, unknown) — default: auto
coverage.status.project.default.threshold (string, unknown) — default: 30%
coverage.status.patch (string, unknown) — default: off

Explore the interactive analysis

See the full architecture map, data flow, and code patterns visualization.

Analyze on CodeSea

Related Dashboard Repositories

Frequently Asked Questions

What is bottom used for?

Cross-platform graphical process/system monitor for terminal (like htop/top) clementtsang/bottom is a 10-component dashboard written in Rust. Well-connected — clear data flow between components. The codebase contains 164 files.

How is bottom architected?

bottom is organized into 4 architecture layers: Collection, Data Management, UI Rendering, Application Logic. Well-connected — clear data flow between components. This layered structure enables tight integration between components.

How does data flow through bottom?

Data moves through 5 stages: System Collection → Data Ingestion → Data Processing → Widget Rendering → Event Handling. Continuous system monitoring pipeline that collects metrics, stores them in time-series buffers, and renders real-time visualizations This pipeline design reflects a complex multi-stage processing system.

What technologies does bottom use?

The core stack includes sysinfo (System metrics collection), ratatui (Terminal UI rendering), clap (Command-line argument parsing), crossterm (Cross-platform terminal control), timeless (Time-series data management), regex (Process and data filtering), and 1 more. A focused set of dependencies that keeps the build manageable.

What system dynamics does bottom have?

bottom exhibits 3 data pools (Time Series Buffer, Process Data Store), 2 feedback loops, 3 control points, 2 delays. The feedback loops handle polling and polling. These runtime behaviors shape how the system responds to load, failures, and configuration changes.

What design patterns does bottom use?

4 design patterns detected: Time-series Storage, Widget System, Feature Flags, Cross-platform Abstraction.

Analyzed on March 31, 2026 by CodeSea. Written by Karolina Sarna.