SA

Sampler Dashboard

Terminal dashboard for visualizing shell command output

Dashboards & Startpages ★ 14.8k stars Easy setup GPL-3.0

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