Building a Personal Bandwidth Dashboard on macOS

Every six months somebody on Hacker News publishes "I built a personal monitoring stack with Prometheus and Grafana." It's beautiful, it's fun to set up on a Saturday, and it's wildly overkill for the actual question: how much bandwidth is each app on my Mac using? You don't need a TSDB, a Docker compose file, or a reverse proxy with TLS. You need a bandwidth dashboard macos that fits on one screen, lives in your menu bar, and gets out of the way. Here's how to build one without burning a weekend.

The thesis: a menu bar app handles the live and recent layer, occasional CSV export handles archival analysis, and you're done. No services to babysit, no scrape configs to edit, no panels to maintain.

What a bandwidth dashboard macos users actually need

Strip away the Grafana fantasy and ask what you'll actually look at:

1. A current rate. "Is something using bandwidth right now?" — the most common question, asked dozens of times a day.
2. A per-app breakdown. When the answer is "yes," you want to know which app.
3. Recent history. Last hour, last day, maybe last week. Enough to spot a pattern.
4. Occasional deep dives. Once a month you want to compare this month to last month, or correlate with something else.

That's it. That's the whole product. Most "personal monitoring" stacks ship with tens of dashboards because the tools encourage it. You don't need them.

The two-layer design

Split the problem into a live/recent layer and an archival layer.

Live + recent: a menu bar app

A menu bar app is the right shape for the first three needs. It's always running, it's a single click away from your current activity, and it doesn't take screen real estate when you're not looking at it. The information density of a menu bar icon — current rate as a small graph or two numbers — is exactly what "is something using bandwidth right now" wants.

Pick one with these properties and you're set:

• Shows a live rate in the menu bar at a glance
• Has a popover or window with per-app breakdown
• Folds helper processes under their parent app (so "Slack" is one row, not seven)
• Keeps at least a day of history, ideally a week or more
• Is signed and notarized so macOS doesn't flag it

ova ships with all of these. About 3 MB, samples at roughly 1 Hz, runs on macOS 14 and later (Apple Silicon and Intel), data stays local, no telemetry.

Archival: occasional CSV export

For the once-a-month "compare this month to last" question, you don't need a live system. You need a flat file. Export a CSV from your bandwidth monitor, throw it in a notebook (Jupyter, Observable, whatever), and run the queries.

This is also the place to do interesting analysis: hour-of-day heatmaps, top destinations by app, week-over-week growth. You don't need it live — running it once a month is fine — and your laptop doesn't need to host a Grafana instance to do it.

If your monitor stores data in SQLite (ova does, in ~/Library/Application Support/ova/), the export is one command:

sqlite3 -header -csv \
  ~/Library/Application\ Support/ova/<file>.sqlite \
  "SELECT timestamp, app, bytes_in, bytes_out FROM samples" \
  > ~/Desktop/bandwidth.csv

Then load it in Python or R or DuckDB and you've got the heavy-lifting layer of a Grafana stack with one query and zero infrastructure.

Why not Grafana?

Grafana, Prometheus, InfluxDB, Loki — they're great tools for fleets. For one Mac, the operational overhead is wildly out of proportion. You'd need:

• A Prometheus instance running locally (RAM, disk, port)
• A custom exporter that reads proc_pidinfo or nettop output (someone has to write and maintain it)
• Grafana running locally (Java/Go process, port, database)
• Dashboards to author and version
• A reason to log into the dashboard regularly (you won't)

After the initial Saturday-afternoon glow, the stack rots. You upgrade macOS and the exporter breaks. Grafana asks for a password reset. You forget about it for three weeks and miss the very anomaly you built it for.

A menu bar app stays out of your way. You see the rate every time you glance at the clock. The bandwidth dashboard macos workflow is built into your routine, not a website you have to remember to visit.

Step-by-step setup

Concretely, here's how to put your dashboard together in 15 minutes.

Step 1: install the menu bar app

Install ova. It's about 3 MB. Drag to Applications, launch, allow the requested permission for reading network statistics, and you're done. It immediately starts sampling at roughly 1 Hz and showing the current rate in the menu bar.

Step 2: configure the menu bar display

Most menu bar bandwidth tools let you choose what to show. Common options:

• Current up/down rate (e.g., ↓ 2.1 MB/s ↑ 80 KB/s)
• A small sparkline of the last minute
• Just an icon that lights up when active

Pick one. The two-numbers display is the densest. The sparkline is the most "glance-able." There's no wrong answer; pick the one you'll actually read.

Step 3: pin a few apps

Some monitors let you mark certain apps as "watched" — they show up first in the breakdown view. Useful pins for most people:

• The browser you live in (Chrome, Safari, Arc, Firefox)
• Your work chat (Slack, Discord, Teams)
• Your dev tools (Docker, VS Code, your simulator if you do mobile)
• Cloud sync (Dropbox, iCloud's cloudd, Google Drive)

You'll know within a week which apps you actually want pinned and which were optimistic.

Step 4: verify history works

The whole point of the recent layer is to be able to scrub back. Open the popover or window, pick a time range like "last 24 hours," and confirm you see a chart with peaks and troughs. If you don't, the app isn't persisting data and you've got a glorified nettop. Move on to a different tool.

Step 5: schedule a monthly export

Add a calendar reminder for the first of the month: "Export bandwidth data, run heatmap notebook." Five minutes once a month. That's your archival layer.

What to look at

Once you have the dashboard running, here are the questions worth checking on a regular cadence.

Daily glance

Open the breakdown view. Scan for surprises. If Chrome is at the top, that's normal. If cloudd is at the top during work hours, ask why (probably iCloud catching up, possibly Photos uploading). If something you don't recognize is at the top, investigate.

Weekly

Look at the per-day total. Is it consistent? A 5x spike on a single day means either you did something different (downloaded a game, had a big call) or something automatic ran (Time Machine to a remote target, system update).

Monthly

Run the heatmap. Top apps by month. Compare to the previous month. Trends over time tell you whether your bandwidth is creeping up — usually because of a new app you forgot to question.

See ova in action

A glance-able menu bar bandwidth monitor — local, signed, ~3 MB.

Download for macOS

A worked example

A real pattern from one user's setup:

• Live rate: small sparkline in the menu bar. Glances cost zero time.
• Per-app view: bound to a hotkey that opens the ova popover.
• Weekly check: every Friday afternoon, the user opens the 7-day view and notes the top three apps. Anything in the top three that wasn't the previous Friday gets a sentence in their journal explaining why.
• Monthly export: launchd job dumps a CSV on the first of each month. A small Observable notebook plots the heatmap and the top-10-by-app list. Total time: 90 seconds, once a month.

That's the entire system. No Prometheus, no Grafana, no reverse proxy, no auth, no ports, no logs to rotate. The "dashboard" is the menu bar plus a notebook that opens once a month.

When you actually do need a server

There are cases where a centralized stack is correct:

• You manage multiple Macs (a small team, a household, a fleet of build machines)
• You want correlations with non-Mac data (router logs, smart-home traffic, work VPN usage)
• You have a real-time alerting need ("page me if upload exceeds 100 MB/s for more than five minutes")

Those cases justify the operational cost. For one personal Mac, they don't.

Wrapping up

A bandwidth dashboard macos users will actually open doesn't need a stack. It needs a menu bar app that always shows the current rate, a per-app breakdown for when something looks off, and an export path for the rare deep dive. That's the whole thing.

If you want the simple version, install ova — about 3 MB, macOS 14 and later, samples at roughly 1 Hz, all data stays in ~/Library/Application Support/ova/ on your machine, no account required, one-time payment with lifetime updates and a 14-day refund. Five minutes from download to dashboard, no compose files in sight.