Dashdot

What is Dashdot?

Dashdot shows CPU, memory, storage, network and GPU usage in a clean, modern interface that is configured almost entirely automatically from the host it runs on.

Best for

A good-looking system stats page with no setup

Why choose Dashdot

Dashdot shows a server's vital signs in the cleanest way available. CPU, memory, storage, network and GPU usage appear in a modern interface that is configured almost entirely automatically from the host it runs on — there is essentially nothing to set up beyond mounting the right paths. It reads GPU data and per-disk storage properly, which is where many general-purpose dashboards fall down, and it presents information as smooth gauges and graphs rather than tables. The whole thing is one container, and the look is the reason people choose it: it takes no effort and it looks deliberate.

Replaces

• Netdata
• Glances
• Cockpit

Key features

• CPU, RAM, disk and network graphs
• GPU metrics where available
• Optional storage breakdown per mount point
• Customisable accent colour and widgets

What to watch out for

It is a display, not a monitoring system. There is no history beyond a short rolling window, no alerting, and no way to look at yesterday. Anything it cannot detect automatically — a GPU in an unusual setup, a network interface inside a container namespace — needs the correct host paths and devices mounted, and getting that wrong produces a page that looks complete but reports zeroes. Because it reads from the host, running it in a container requires careful mounts and often host networking or a privileged mode, which is a security consideration on a shared machine. It is also one host per instance with no built-in aggregation.

How to deploy

• Docker with host mounts for /proc and /
• Mount the Docker socket for container stats
• Add auth via reverse proxy

Getting started

Run it with the host's proc, sys and root paths mounted read-only, plus the devices needed for GPU reporting, and confirm that each gauge shows a plausible number rather than a zero — a zero usually means a mount is wrong rather than a genuinely idle system. Give each host its own instance and link them rather than trying to aggregate. Add a real monitoring system alongside it if you need history or alerts, because this is the surface you glance at. Keep it on the internal network and out of any public exposure, since the appliance-like access requires privileged mounts.

Typical setup

One container per host with the host's proc, sys and root paths mounted read-only plus the devices needed for GPU reporting. Every gauge is checked to show a plausible number rather than a zero, because a zero usually indicates a wrong mount rather than an idle system. Multiple hosts are handled as separate instances that are linked rather than aggregated. A real metrics system runs alongside it for history and alerting, since this is the surface glanced at rather than the record. It stays internal, given the privileged mounts it requires.

Who should look elsewhere

Do not use it as your only monitoring, because it records nothing and alerts on nothing. Avoid it if you cannot grant the mounts and privileges it needs, since a partially-configured instance is worse than none. And if you need to compare several hosts on one screen or look at trends over weeks, a metrics system with dashboards is the right shape of tool.

Project health

• GitHub stars: 3,547
• Last code push: 2026-10-01
• Open issues: 60
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.