system-ops — Watching a Server Without Installing an Agent
Lightweight web console for systemd, journald, and process metrics on a Linux VPS.
I run infrastructure for multiple freelance clients on a single VPS. Each client has their own services, their own databases, their own backup schedules. When something breaks at 2 AM, the debugging ritual is always the same: SSH in, run systemctl status, tail journalctl, open htop, repeat for the next service.
There was no single pane of glass. Just a terminal and a prayer.
What It Watches
system-ops is a web console that streams three things over WebSockets:
- systemd service states — running, failed, restarting, all in real time
- journald log streams — inline, filterable per service, no separate terminal pane
- Process metrics — CPU and memory per service, graphed without manual polling
Open the dashboard, see everything. The simulator below shows what that replaces.
operations workflow
Minimal Daemon Footprint
The whole point is watching a resource-constrained box without making it more constrained. A heavy monitoring agent — one that buffers metrics, runs its own database, and eats 200MB of RAM — defeats the purpose on a small VPS.
The system-ops daemon is deliberately light. It reads from systemd and journald APIs that already exist on the host. No custom metric collectors, no embedded time-series database.
Backup Visibility
Postgres backup dumps run on a cron schedule. When a backup fails silently — disk full, permission error, connection timeout — you usually find out during a restore, not when it happens.
system-ops tracks backup job status alongside service health. A failed backup shows up in the dashboard with the same urgency as a crashed service, not buried in a log file you'll never check.
Where It's Going
Active development. The UI is moving toward a Linear/Vercel-style aesthetic — clean typography, tight spacing, status dots that mean something at a glance. Docker support is being added so containerized services get the same treatment as native systemd units.
The goal hasn't changed: see what's happening on your server without SSHing in and running five commands.