The Kitaso blog

A server to monitor a server is crazy

2026-07-15T08:00:00Z

Modern infrastructure design is about complicating so much that we've forgotten that our own laptop is the interface to it all. So why not monitor from there instead?

What are you on about?

Over the years I've managed many servers, from small side projects to professionally for the companies that I've worked for.

The company servers were all managed and monitored through the infrastructure platforms that we used, but my side project servers were just there and usually it took an e-mail by a sporadic user to let me know that they were down to begin with.

Enter my own startup, Elmtrail. We run lots of servers for our AI automation platform that are all critical to stay up and running.

Our philosophy of infrastructure design is to keep it simple and easy to manage. We use Kamal to manage our services and run deploys and run everything on Hetzner that way.

For monitoring those servers, we could've setup Grafana with various datasources and whatever else. But then, who was going to monitor the Grafana server? Would I have to setup another server? Why is this such a pain? I just want to look at CPU, memory and disk usage of my servers.

Enter Kitaso

What if, I thought, I'd just SSH into my servers and get the metrics I need? What if, I thought further, I would store these collected metrics locally and display them in a simple dashboard?

That is how Kitaso was born. The first version would ping the server and display and store the metrics it fetched every minute.

Obviously, I needed a way to monitor the server when my laptop wasn't on to collect the metrics. This was easily fixed by creating a small bash script that would collect the same metrics on each server and store them in a SQLite database. My client would then fetch these metrics and display them in the dashboard.

A child can do the washing, as we say in the Netherlands.

It turns out, it is a bit more complicated than adding the word 'just' in every sentence. However, the basic premise is correct.

The result

Kitaso fits the way we run infrastructure at Elmtrail: keep it simple enough that it stays out of the way, and spend the attention on the product instead.

It has alerted us early of a few issues, and it lets me look back at what a server was doing when something went wrong. I open it every day.

It does not page me at night. Notifications fire from my Mac, so a closed lid means the alert waits. The collector keeps the history, so the incident is on the chart in the morning.

Two servers are free, with no account and no time limit: kitaso.app.

Kitaso vs Prometheus and Grafana: a stack to run, or an app to open

2026-06-23T08:00:00Z

Prometheus and Grafana are the default open-source answer to monitoring, and above a certain scale they are the right one. The question is whether you are at that scale. Most people with a handful of boxes are not.

What Prometheus and Grafana means

It is shorthand for four or five separate processes you assemble yourself:

Prometheus scrapes metrics on a schedule, stores them in its own time-series database, and answers queries in its own query language, PromQL. It also evaluates alert rules.
node_exporter runs on each host and exposes that host's metrics on a port for Prometheus to scrape.
Grafana reads from Prometheus and draws the dashboards.
Alertmanager takes the alerts Prometheus fires and routes, groups and silences them.
cAdvisor, optionally, for per-container metrics.

All free, all open source, all industrial grade. Nothing below is a knock on the quality.

	Kitaso	Prometheus + Grafana stack
You run	One Mac app	Prometheus, node_exporter, Grafana, Alertmanager, often cAdvisor
On each server	An optional scheduled collector, no open port	node_exporter on a port, plus exporters per service
Setup	Add a host, see a chart	Scrape configs, storage, dashboards, PromQL rules, alert routing
Querying	Pick a metric and a time range	PromQL
Central host	None, the app is your Mac	Its own always-on box
Price	$39 once (1 year of updates included), 2 servers free forever	Free, self-hosted

What the stack costs when the software is free

Configuration and upkeep. You write scrape configs. You plan retention and storage. You build dashboards, or import someone else's and adjust them. You write alert rules in PromQL and routing in YAML. The components support TLS and basic auth, but not by default, so in practice every exporter and port stays off the public internet behind firewall rules or a private network. There are thirty-minute docker-compose demos for all of this; a thirty-minute production setup is not a thing.

Grafana is the one piece of this I have run myself, and not for long. Getting a chart on screen was quick. Knowing it well enough to change it confidently was not: the query editor, the datasource settings, template variables, panel options, and the gap between what a dashboard asks for and what Prometheus actually stores. It is a skill you keep up, and it decays if you touch it twice a year.

The stack also wants a home: an always-on box of its own. Watching a few small servers means standing up another server, and on small boxes that stack can use more memory than the applications it is watching.

What you get in exchange

Real things. A shared Grafana that is always up and readable by a whole team from any browser. PromQL, which answers questions Kitaso cannot: rates of change, percentiles across hosts, arbitrary math over any series. An exporter for nearly everything. Alertmanager routing for actual on-call schedules, firing around the clock from a machine that is always on. Retention and resolution entirely under your control.

If you need any of that, use the stack and don't look back.

The other trade

Kitaso is the opposite deal. You add a host and you see a chart. On each server there is at most a small scheduled collector writing metrics to a local SQLite file — no port, nothing new to secure. The Mac pulls everything over the SSH access that already exists. Alerts are thresholds set in a sheet, and they fire from the Mac while it is awake; the collector keeps the history overnight but does not page you. There is no PromQL, no shared web dashboard, no federation.

The stack is the right answer to a problem you may not have yet. Until you do, the first two servers are free at kitaso.app.

Kitaso vs Netdata: a resident agent, or SSH polling

2026-06-20T08:00:00Z

Netdata puts a resident agent on every server and serves a real-time dashboard from the box itself. Kitaso puts a Mac app in front of the SSH access you already have. The difference that matters is what runs on the machine being watched.

Everything below about Netdata comes from its documentation and pricing page, checked on 4 September 2026.

Two shapes

Netdata's agent runs continuously on each host. It collects at one-second granularity by default, ships over 800 collectors that auto-discover things like Postgres, NGINX and Redis, serves a web dashboard from the box on port 19999, and runs machine-learning anomaly detection locally. The agent is GPLv3 and much of it works fully offline. Netdata Cloud adds a single view across machines.

Kitaso runs on the Mac. It opens an SSH connection per server, runs one batched command, parses the output and charts it. The optional collector on each server is a scheduled job that runs and exits — no resident process, no open port.

	Kitaso	Netdata
On each server	A scheduled job that runs and exits	A resident agent, always running
Open ports	None	A local dashboard on port 19999
Granularity	Per server, down to every second	Every second, everywhere, by default
Metrics	CPU, RAM, disk, load, Docker	800+ collectors, app dashboards, ML anomaly detection
Dashboard	Native Mac app	Web UI per node, or their Cloud for a fleet view
Price	$39 once (1 year of updates included), 2 servers free forever	Agent free; Cloud free to 5 nodes, then Homelab $90/yr or $4.50/node/month, from netdata.cloud/pricing on 4 September 2026

Two rows in that table are easy to misread.

Granularity. Kitaso's polling interval is set per server and goes down to one second, so a short spike does not slip past a box you are actively watching. But a local agent samples every metric every second continuously and cheaply, while SSH polling at one second costs far more per sample. Netdata holds that resolution everywhere, all the time. Kitaso reaches it where you ask for it.

Price. Netdata's agent is genuinely free and unlimited. The five-node limit applies to Netdata Cloud, the layer that gives one view across machines. Past five nodes you pay for Cloud or self-host a parent node to aggregate. The per-node dashboards stay free either way.

What the agent costs on the box

An agent collecting hundreds of metrics every second, keeping its own retention and training anomaly models locally, uses real CPU, memory and disk on the machine it is watching. That is not a flaw; it is what the capability costs. On a large application server it disappears into the noise. On a 2 GB VPS running one Rails app it is a visible share of the box.

Kitaso's footprint on the server is one SSH command per poll — or, with the collector installed, a scheduled shell script writing to a local SQLite file. Nothing runs between polls and nothing listens on a port.

Which one

For deep, always-on, per-application visibility with per-second history and anomaly detection on every box, Netdata does considerably more than Kitaso and the agent costs nothing. For real-time troubleshooting it is hard to beat.

For a handful of servers seen at a glance from a Mac, with almost nothing running on the servers themselves and the history on your own machine, that is what Kitaso is for. Two servers free at kitaso.app.

Kitaso vs Beszel: a self-hosted hub, or an app on your Mac

2026-06-18T08:00:00Z

Beszel and Kitaso answer the same question — how do you watch a handful of Linux servers without standing up an observability platform — and they put the dashboard in opposite places. Beszel puts it on a server you host. Kitaso puts it in an app on your Mac.

Everything below about Beszel comes from its documentation and GitHub repository, checked on 4 September 2026. It is free, MIT licensed, and had over 25,000 stars at that point.

Two shapes

Beszel is a hub and agents. The hub is a single Go binary with an embedded SQLite database; you run it somewhere central and it serves a web dashboard with user accounts. On each monitored machine runs a small agent. Hub and agent authenticate with an SSH key, and depending on the setup the hub connects to the agent or the agent opens a WebSocket to the hub. Both parts are light.

Kitaso has no hub. The Mac app opens an SSH connection to each server, runs one batched command, parses the output and draws it. History goes into SQLite on the Mac. A scheduled collector on each server is optional; installed, it writes metrics to a SQLite file on that box, and Kitaso pulls the rows when it next connects, so history keeps accumulating while the Mac is closed.

	Kitaso	Beszel
Front end	Native Mac app	Self-hosted web hub
On each server	Optional scheduled collector (shell + SQLite)	A small agent binary
Also required	Nothing else	The hub: a server, TLS, an admin account
Where history lives	SQLite on your Mac	SQLite in the hub you host
Access	Your Mac	Any browser, multiple user accounts
Alerting	From the Mac, while it is awake	From the hub, around the clock
Platforms watched	Linux	Linux, FreeBSD, macOS, Windows
Price	$39 once (1 year of updates included), 2 servers free forever	Free, MIT

What Beszel does that Kitaso does not

The dashboard exists without your laptop. It runs on an always-on box, reachable from any browser and any phone, with real user accounts. A colleague can open it; an on-call rotation can share it. Kitaso is single-operator — there is no URL to send anyone.

Because the hub is always on, its alerts are too. Kitaso's alerts fire from the Mac and only while the Mac is awake. The collector keeps filling the history overnight, but it does not page you.

Beszel is also free and open source, and it watches more than Linux: FreeBSD, macOS and Windows, plus GPUs and disk health. Kitaso reads Linux boxes over SSH and nothing else, and costs $39.

If more than one person looks at the dashboard, or the fleet is a mix of machines rather than a row of Linux VPSes, Beszel covers ground Kitaso does not.

What running no hub buys

The hub is a server. In practice it lives on a small VPS, in Docker, behind a reverse proxy with TLS if it is reachable from the internet, with an admin login. It has a disk that can fill, updates to apply, and a failure mode of its own: while the hub is down, nothing is being recorded.

Kitaso has no equivalent piece. The servers report to nothing except the Mac that connects to them, over SSH access that already exists. No account, no open port, no certificate to renew.

Which one

One question decides it: does the dashboard need to exist without your laptop?

If yes — a team, a rotation, a phone, or alerts that must fire at 3am — run Beszel. It is free and built for exactly that.

If one person with a Mac watches a handful of Linux boxes, and another server to host, secure and patch is the thing being avoided, that is the gap Kitaso fills. The first two servers are free at kitaso.app.

Kitaso vs Datadog: the arithmetic for five servers

2026-06-16T08:00:00Z

Datadog is an observability platform for teams running hundreds of hosts who need metrics, traces and logs correlated in one place. Kitaso is a Mac app that charts CPU, memory, disk, load and Docker stats for the Linux boxes you own. They are not competitors at Datadog's scale. They overlap at the small end, where both can do the job and the price difference is three orders of magnitude.

The pricing

Every Datadog figure here comes from datadoghq.com/pricing, checked on 4 September 2026. Vendor pricing moves, so check it again before acting on the arithmetic.

	Kitaso	Datadog
Model	One-time purchase	Per-host, per-month subscription
Infrastructure	$39 once (1 year of updates included), unlimited servers	$15/host/month (annual), $18 on-demand
APM	Not offered	+$31/host/month (annual)
On each server	An optional scheduled collector writing to SQLite	A resident agent reporting to the cloud
Free tier	2 servers, forever, no account	Up to 5 hosts, 1 day of retention
Where your data lives	Your Mac	Datadog's cloud

Five servers on the annual Infrastructure plan is 5 × $15: $75 a month, $900 a year. Add APM and it is around $230 a month, roughly $2,760 a year, every year. Infrastructure billing is high-water mark — hosts are metered hourly and the 99th percentile is billed, so a brief spike is forgiven while a sustained busy week sets the bill for the whole month.

Kitaso is $39 once, with a year of updates included. Two servers are free with no account, so it can be tried on real boxes before anything is paid.

What the difference buys

Datadog: distributed tracing, log aggregation, hundreds of integrations, anomaly detection, retention measured in months, and dashboards a whole on-call rotation reads from any device.

Kitaso: CPU, memory, disk, load and Docker stats, per server, charted on your Mac, with threshold alerts. That is the complete list. No tracing, no log aggregation, no shared dashboard, no cloud.

At a few hundred hosts, Datadog earns its price and Kitaso cannot do the job at all. At five, most of what the bill covers is capability that never gets opened.

What five servers actually need

Is CPU pegged, is memory running out, is a disk filling up, are the containers running, was this happening yesterday too, and will you hear about it before a user emails.

Kitaso answers those six questions and stops there. The optional collector on each box keeps gathering while the Mac sleeps, so an overnight incident is on the chart in the morning. That is history rather than paging: live alerts fire from the Mac, while it is awake.

If a Datadog quote is sitting in an inbox and the fleet is five servers, the small thing is worth trying first. Two servers free at kitaso.app.

A server's vitals in one SSH round-trip

2026-06-09T08:00:00Z

Kitaso needs to answer one question, over and over, for every server: how are you doing? Most monitoring tools answer it by installing an agent on the box. I didn't want to install anything. My Mac can already SSH into all of my servers, so why not use that?

The naive version is one SSH call per metric. One for CPU, one for memory, one for disk, one for docker stats. With four servers on a short polling interval you are suddenly opening a lot of connections, latency stacks up, and the charts start to stutter.

So Kitaso sends one batched command per poll and parses the combined output on the Mac. Roughly this:

{
  echo "===CPU==="    ; cat /proc/stat | grep '^cpu '
  echo "===MEM==="    ; cat /proc/meminfo
  echo "===LOAD==="   ; cat /proc/loadavg
  echo "===DISK==="   ; df -PB1 -x tmpfs -x devtmpfs -x overlay
  echo "===DOCKER===" ; docker stats --no-stream --format '{{json .}}' 2>/dev/null
}

One connection, one block of text. The server does almost nothing. Reading /proc is a memory copy, not a measurement. The kernel already counted everything for you; the only cost is shipping the text over SSH.

CPU is a delta, not a number

Fun detail: /proc/stat does not tell you CPU is at 40%. It gives you cumulative counters since boot. A single reading is meaningless. You need two readings and the percentage is the ratio of busy time to total time between them:

busy  = (total₂ − idle₂) − (total₁ − idle₁)
cpu%  = busy / (total₂ − total₁) × 100

This is also why the CPU line is empty right after you add a server. There is no previous sample to diff against yet. One interval later, it starts moving.

CPU over 7 days. The line breaks where collection actually stopped, instead of guessing.

Docker without exposing the socket

The docker stats line makes people squint. Doesn't that need the Docker socket? It does, but on the server, where the socket already lives and already belongs to the user you SSH in as. Nothing gets exposed over TCP and no port opens. Kitaso just runs docker stats in the shell it is already in and gets every container's CPU and memory, plus the image tags. When an image tag changes, that shows up as a deploy marker on the charts, so a CPU spike has a story attached.

To be fair, this is also the one line in the batch that costs the server real work. Reading /proc is free; asking the Docker daemon about every container is not. It is still one command in one connection, but the server does almost nothing is most true on boxes without Docker.

Your keys stay yours

Kitaso does not implement SSH. It shells out to the system ssh binary, the same one you use in a terminal. That means your ~/.ssh/config, your keys, and your ssh-agent all work exactly as they already do, and servers behind a bastion work through jump hosts. The app never copies or uploads your keys; there is nothing new to trust with your credentials.

Why I care about round-trips

I monitor from a laptop, not from a box in the same datacenter. Every connection crosses the open internet, sometimes on hotel Wi-Fi. Batching means one connection per server per poll instead of five. That is the difference between charts that feel live and charts that feel like they are buffering.

It also keeps the server boring. No listener to patch, no agent to update, no new attack surface. Just ssh, /proc and df. The tools that were already there.

Want history while your Mac is off? That is the one thing Kitaso can install on a server: a tiny shell + SQLite collector on a timer.

The tiny daemon that watches while your Mac sleeps

2026-06-04T08:00:00Z

A Mac app that polls servers over SSH has one obvious hole: laptops sleep. Close the lid and nothing is collecting. Kitaso is honest about it and draws a gap in the chart instead of a made-up line, but a gap is still a gap.

I wanted the history to keep rolling while my Mac is off, without turning the whole thing into an agent platform. So I wrote the smallest collector I could get away with: a shell script, a scheduled job, and a SQLite file. It is the only thing Kitaso ever installs on a server, and it is optional.

What actually gets on the box

Three things, and you can read all of them:

collect.sh, a plain POSIX shell script that does the same /proc + df + docker stats reads the live poller does, and writes them to a local SQLite database instead of shipping them over the wire.
A scheduled job that runs it every minute. On a systemd host that is a small timer unit; on boxes without systemd it is one cron line:

* * * * * /opt/kitaso/collect.sh >> /opt/kitaso/collect.log 2>&1

A SQLite database that grows by one small row per minute, with retention pruning to keep it bounded.

No resident process, no listener, no open port. The scheduler wakes the script, the script writes a row, the script exits. The scripts together are about 35 KB of plain shell you can open in a text editor, and the whole install directory is about 50 KB before the database starts filling.

The schema is nothing special

A trimmed version of the table it writes:

CREATE TABLE snapshots (
  ts         INTEGER NOT NULL,   -- unix seconds
  cpu        REAL,
  mem_used   INTEGER,
  mem_total  INTEGER,
  load1      REAL,
  containers TEXT,               -- JSON
  PRIMARY KEY (ts)
) WITHOUT ROWID;

SQLite handles a once-a-minute writer without breaking a sweat. That's it. No time-series database, no query language.

Installing is one click, so is removing

There is no provisioning step. Kitaso pushes the script over the SSH connection it already has, sets up the timer or cron line, and runs the first collection. One click in the app.

From then on, Kitaso pulls the collected rows whenever it connects and merges them with its own live polling. When both sources have a reading for the same moment, the live one wins, so the charts never double up.

One thing the collector does not do is page you. It keeps the history; alerts still fire from your Mac, while it is awake. The 3am incident is on the chart in the morning, not on your phone at 3am.

Removing it is the same click in reverse. Or do it by hand: it is one directory and one scheduled job.

That removability is the point. A monitoring tool you can fully delete with rm and one scheduler entry is a monitoring tool you can trust to be small. The collector only ever reads what the kernel already knows, and your data never leaves the server until your own Mac pulls it back.

The live side of this, reading a whole server in a single connection, is in A server's vitals in one SSH round-trip.

Who monitors the monitor?

2026-05-28T08:00:00Z

When I went looking for something to watch my servers, every option came down to the same thing: run a server to monitor your servers.

Either a hub that I would have to install, secure and keep patched. Or an account on someone's cloud with a bill per host. Both mean adding a moving part just so I can watch my other moving parts. And when that part breaks, who monitors the monitor?

I should say up front that I am no expert on the monitoring landscape. Big teams have good reasons for their observability stacks and I am not going to pretend otherwise. But I don't have a big team. I have a Mac, an SSH config, and a bunch of Linux boxes on Hetzner that mostly behave.

What do I actually want to know about those boxes? Is the CPU pegged. Is memory running out. Is a disk filling up. Are my Docker containers still running. And please tell me before my users do.

None of that needs infrastructure. My Mac can already SSH into every one of those servers. Reading /proc and running df costs a server basically nothing. So that is what Kitaso does: it is a Mac app that polls my servers over SSH and draws charts. No hub, no account, no subscription. The history is a SQLite file on my own disk.

But your Mac sleeps

True. When my laptop is closed, nothing is polling. Kitaso is honest about it: the chart shows a gap instead of making up a line.

If the gap bothers you, there is exactly one thing Kitaso will ever install on a server: a small collector. A shell script, a scheduled job, and a SQLite database. It writes the same metrics locally every minute, and Kitaso pulls the history back in the next time it connects. No open port, no resident process. Removing it is deleting one directory and one scheduled job.

The trade

A hosted dashboard gives you 24/7 eyes and someone else's uptime. In exchange you get an account, a subscription, and one more system in your critical path.

A Mac app gives you no accounts, no bills, and data on your own disk. In exchange, live alerts only fire while your Mac is awake, and the history gap is covered by one tiny scheduled collector. The collector fills the chart, not the pager.

For me the second trade wins easily. It just didn't exist as a polished native app, so I built it. The first two servers are free: kitaso.app.

Curious how it reads a whole server in a single connection? I wrote that up in A server's vitals in one SSH round-trip.

Alerts that don't cry wolf

2026-05-21T08:00:00Z

The fastest way to make me ignore alerts is to send too many. If CPU brushing 90% for four seconds during a deploy pages me, I will mute the whole thing within a week. And then the real outage arrives in silence.

So when I built alerting into Kitaso, the rule was simple: crossed a threshold and is in trouble are two different questions. Kitaso only bothers me about the second one.

A spike has to last

Crossing a threshold does not fire an alert. It starts a timer.

normal  ──(value > threshold)──▶  warming  ──(held for the warm-up window)──▶  alerting
   ▲                                  │
   └──────(value dips below)──────────┘   timer cancelled, nothing sent

If the value drops back under the line before the warm-up window is over, the timer is cancelled and nothing happens. The deploy spike comes and goes and you never hear about it. Only a crossing that stays crossed for the whole window becomes an alert.

Recovery has to last too

The same logic runs on the way down. One sample under the threshold doesn't mean recovered. It might bounce right back. So Kitaso waits out a recovery window before it declares the all-clear, and a rise back above the line cancels that timer just like on the way up.

Flapping is what destroys trust in an alerting system. An alert that fires, recovers, fires, recovers, teaches you to stop reading.

Except when things get worse

There is one exception. If a metric is already alerting at the warning level and then crosses the critical threshold, that fires immediately. No new warm-up. You already waited once to confirm the problem is real. Making you wait again to learn it got worse would be silly.

It looks closer when something is up

While a metric is warming, alerting or recovering, Kitaso polls that server faster, up to your configured interval. So you get fine-grained samples through the interesting part of an incident. After ten minutes of sustained alerting it relaxes back to the normal cadence, so a long outage doesn't hammer the box.

One full disk is one alert

A server running Docker can have a dozen overlay mounts all backed by the same physical disk. A naive monitor sees twelve filesystems crossing 90% and sends twelve alerts. Kitaso deduplicates disk alerts by the underlying device. One full disk, one alert. And you can exclude specific mounts per server when you genuinely don't care about them.

And when you already know

Doing maintenance and expecting things to get loud? Snooze the server, from five minutes to until tomorrow.

One honest limitation

Notifications fire from your Mac. If the lid is closed at 3am, nothing pages you; the server-side collector keeps the history, so the incident is on the chart in the morning, but that is a post-mortem, not an alarm. If you need something that wakes you regardless, pair Kitaso with a simple uptime pinger for the is-it-down case. Kitaso is the everything-else.

All of this is configurable per metric and per server: the thresholds, the warm-up and the recovery windows. The defaults are conservative on purpose. When Kitaso notifies me, I act on it. That is the whole point.

Curious how the readings behind these thresholds are collected? See A server's vitals in one SSH round-trip.