Sampler Dashboard
Terminal dashboard for visualizing shell command output
Sampler is a tool for building live terminal dashboards from the output of shell commands, displaying it as charts, gauges, and counters. It is configured with a simple YAML file for quick operational views.
Key features
- Terminal-based charts
- Shell command data sources
- YAML configuration
- Gauges and counters
Pros & cons
Strengths
- Runs in a terminal
- No web stack needed
Trade-offs
- Limited to terminal display
- Not for shared use
Sampler Dashboard replaces
Last reviewed Aug 26, 2026 · 768 words
Twenty lines of YAML and a single 64 MB binary get you a live terminal dashboard of anything a shell command can print. That is Sampler's entire proposition, and for a homelab operator sitting at an SSH prompt it covers a surprising share of what people spin up Grafana for. It is written in Go, licensed GPL-3.0, has 14,789 stars, and stores nothing: every number on screen is the output of a command it just ran. The catch sits in that last sentence, so start there.
Everything on screen is a command that ran a moment ago
Sampler has no data source, no collector, and no history beyond what fits in the chart width. Each widget lists one or more items, each item has a sample: command, and a rate-ms sets how often it runs. A run chart of CPU temperature and load on a Linux box looks like this:
runcharts:
- title: Load and temperature
rate-ms: 2000
scale: 2
items:
- label: load1
sample: cut -d' ' -f1 /proc/loadavg
- label: cpu_c
sample: awk '{print $1/1000}' /sys/class/thermal/thermal_zone0/temp
sparklines:
- title: Free memory MB
rate-ms: 1000
sample: free -m | awk '/Mem/ {print $7}'
gauges:
- title: Root disk used
rate-ms: 10000
min: 0
max: 100
cur:
sample: df / | awk 'NR==2 {print $5}' | tr -d '%'
Save it as dash.yml, run sampler -c dash.yml, and the chart starts filling. Widget types are run charts, sparklines, bar charts, gauges, text boxes, and ASCII boxes (large-digit counters). Because a sample is any shell one-liner, curl against a JSON endpoint piped through jq works just as well as a local file read, which means a container's /metrics or a Home Assistant sensor is one line away.
Sampler is not a monitoring system, and pretending otherwise hurts
Nothing persists. Close the terminal and the history is gone; nobody else can see it; there is no alert that fires while you are asleep. Sampler does have triggers (a condition command plus actions like a terminal bell, a visual flash, or running a script), and those are handy for "beep when the build finishes", but they only work while the dashboard is open on a screen. For anything that must page you, keep Uptime Kuma or Prometheus doing the real job and treat Sampler as the pane you glance at during an incident. The Grafana versus Prometheus piece explains the collector-plus-dashboard split that Sampler deliberately skips.
Where it beats a browser dashboard
Three situations, in my experience. First, a headless box you reach only over SSH, where opening a browser tab means a tunnel and a login. Second, a five-minute question ("is the RAID rebuild actually progressing?") that does not justify wiring a new panel. Third, a tmux window on a spare monitor, where a dozen numbers updating every second is exactly the right density and a web page would be overkill. Sampler also has an interactive-shell option per item, so you can keep a persistent session open (a database client, a REPL) and sample from it rather than spawning a fresh process on every tick. That makes it cheap even at 500 ms rates.
Where it falls short
Interactivity is limited to pausing, moving, and resizing widgets with the keyboard; there is no zoom, no legend toggling, no click-through. Text rendering depends on your terminal's Unicode support, so some fonts draw the run charts with gaps. The project's release cadence has slowed to a crawl, and the config format has not changed for a long time, which cuts both ways: your YAML from years ago still works, and nothing new is coming. Because it is a single static binary the maintenance burden is close to zero regardless. Compare it to Glances if you want system stats without writing any config at all, and to the dashboards category if the thing you actually want is a wall display.
What I'd do
Keep one dash.yml per host in the same repository as your Compose files, with load, memory, disk, and the two or three application-specific numbers that matter on that machine. Run it inside tmux so it survives a dropped SSH session. Do not try to make it your monitoring; do not put a trigger in it that you would be upset to miss. Used as a glance-at-it pane next to a real alerting stack, it is the most useful 64 MB in the box.
Compare Sampler Dashboard
1 head-to-head comparisons.
Similar dashboards & startpages apps
Portainer CE
Dashboards & StartpagesLightweight management UI for Docker and Kubernetes
Replaces Rancher, Docker Desktop
CasaOS
Dashboards & StartpagesSimple, easy-to-use home cloud system and dashboard
Replaces Google homepage
Glance
Dashboards & StartpagesSelf-hosted feeds and info dashboard
Replaces Heimdall
Web Check
Dashboards & StartpagesAll-in-one OSINT tool for analysing any website
Homepage
Dashboards & StartpagesFast, file-configured application dashboard
Replaces Heimdall
Dashy
Dashboards & StartpagesFeature-rich personal dashboard for self-hosters
Replaces Heimdall