A system monitor that earns its screen space
bottom is a live terminal dashboard for the machine in front of you. It graphs total and per-core CPU use, RAM, swap, network traffic, temperatures, and disk input and output. Separate tables cover capacity, sensors, batteries, and processes. The process view can sort, search, show a tree, and send termination signals. You can zoom graph time ranges or expand one widget when a busy overview becomes too much.
That mix is the reason to install it. Traditional top is everywhere but visually terse. Process-focused tools can be excellent at inspecting one unruly program while giving less context about disk, network, or thermal behavior. bottom keeps a useful overview visible without requiring a browser, daemon, database, or account. Its command name is btm, which avoids colliding with the common Unix utility.
The interface is dense, but it is not fixed. A basic mode resembles htop, built-in and custom themes change the presentation, and layouts can rearrange widgets. Filters hide irrelevant disks or sensors. The latest release adds a configurable default sort order, a small improvement that reflects the project's practical maturity: it is refining daily behavior rather than constantly reinventing the application.
Installation is a solved problem
bottom is packaged unusually well. Linux users can find it in Alpine, Arch, Gentoo, Nixpkgs, openSUSE, Snap, Solus, Void, and other channels, while the project publishes Debian and RPM files. Homebrew and MacPorts cover macOS. Windows users get winget, Scoop, Chocolatey, and an MSI. Conda, mise, Cargo, and prebuilt archives fill remaining gaps. Shell completions are included in release packages.
For most readers, setup is one package-manager command followed by btm. On first launch, bottom tries to create a TOML configuration file with default values in the normal user-specific location for the operating system. The documentation includes a schema for editors that can validate JSON Schema, which lowers the risk of a misplaced option silently failing.
There are a few real caveats. A Snap installation needs mount, hardware, system, and process-control interfaces connected before all widgets work. A Cargo install should use current stable Rust and the locked dependency set. Source compilation is therefore available but rarely the best route when a maintained native package exists.
Graphs use braille characters for higher apparent resolution. If the terminal font cannot render that Unicode range correctly, charts may look broken or flicker strangely. The troubleshooting guide offers two good exits: install and configure a compatible font, or launch with dot markers for a simpler but more portable graph. This is a terminal rendering limitation, not missing system data.
The dashboard is deep where everyday users need it
The strongest widgets are the ones most people check during a slowdown. CPU history separates average and per-core load. Memory includes RAM and swap. Network and disk activity show whether a waiting application is compute-bound or moving data. Temperature and battery tables help on laptops, while disk capacity catches the painfully common full-volume failure.
The process table bridges observation and action. Search and sorting make it easy to find a program by name, CPU, or memory behavior; tree mode reveals parent and child relationships; termination support avoids switching to another command. Expansion mode gives that table the terminal when detailed investigation matters. Recent configuration work lets a preferred sort direction persist.
Customization goes beyond colour. Command-line flags and TOML settings control widget behavior, initial selection, data grouping, update rates, units, filters, layouts, and styles. This is enough to build a compact server view or a wide workstation dashboard. What it does not offer is a system-wide configuration layer. An open request asks for administrator defaults through locations such as XDG_CONFIG_DIRS or Windows ProgramData. Organizations managing shared machines must currently distribute per-user files or wrap the launch command themselves.
Cross-platform does not mean identical data
Official support covers x86 and ARM macOS, x86, 32-bit x86, and ARM64 Linux, plus x86 Windows in 32-bit and 64-bit forms. The README distinguishes those tested targets from unofficial builds for FreeBSD, Android, additional Linux architectures, and Windows ARM. FreeBSD may work but receives limited testing; OpenBSD remains a feature request.
Operating systems expose different information and permissions. On Windows, some temperature sensors may require administrator access, and dual batteries may not appear separately. WSL may omit host temperature sensors, while WSL2 numbers do not necessarily match Task Manager. On macOS, missing process details may be visible only under sudo. The docs correctly warn that granting root access to a monitor is a security decision, not a routine fix.
Privileges do not solve every gap. An open Windows report says bottom could not terminate processes launched by services or scheduled tasks even when the terminal was elevated, although taskkill could force them. Another issue says network activity can show zeros from a different Linux network namespace unless bottom runs as root. Users operating containers, services, or locked-down desktops should confirm the exact metrics and actions they rely on.
Metric coverage is broad but not total. GPU and VRAM load is still under active exploration, and fan speed remains an old feature request. Exact per-process memory bytes, swapped memory, detailed threads, CPU groups, and subtree-only process filtering also appear in the open queue. htop, btop, vendor GPU tools, or platform-native utilities may be better for those specialized questions.
Healthy, documented, and correctly scoped
The repository was pushed on August 8, 2026, and version 0.14.7 was released July 27. The current release includes a packaging compatibility fix alongside the sort setting and internal dependency updates. The 109 open GitHub items combine issues and pull requests, and many visible issues are long-term feature requests rather than recent breakage. Active work in August confirms that the project is maintained.
Documentation is a standout. The README covers every distribution channel, while the separate site explains individual widgets, layouts, flags, configuration files, official and unofficial platforms, development, and known problems. Advice about fonts, Snap permissions, Windows sensors, WSL differences, macOS privileges, and configuration locations makes the project easier to trust.
bottom is excellent for interactive local diagnosis. It is not Prometheus in a terminal: it does not retain long-term history, alert a team, monitor a fleet, or provide shared dashboards. That boundary is healthy. Install it when you want to answer “what is this machine doing now?” quickly, and pair it with a real monitoring system when the answer must survive after the terminal closes.