Context before alerts.
Moniqo understands your server before it starts monitoring. Different servers have different roles, mounts, and critical processes. Generic templates don't work. Context-aware monitoring does.
Discovery-first approach
After installation, the agent collects a complete context snapshot: hardware specs, mount points, running services, filesystem types, storage layout, and capability hints.
You review what was discovered and approve what gets monitored. Nothing runs without your explicit confirmation. No auto-activated alerts you didn't ask for.
Meaningful alerts only
Disk growth prediction, not just a static threshold. OOM kills, not memory usage percentages. Kernel errors, not load averages. Every alert describes what's actually wrong and why it matters.
We deliberately don't alert on CPU usage, load spikes, or generic memory warnings. These are noise — not signals. Our alerts have a very high signal-to-noise ratio.
Relationships & pairing
Moniqo maps your server room automatically, from the same discovery data the agents already collect — no manual diagramming, no CMDB to maintain:
- What runs on what — VMs are matched to their hypervisor, so "storage host degraded" immediately shows which guests are at risk.
- Who mounts what — NFS and CIFS shares are traced from server to every client. When shared storage fills up or stalls, you see every machine it takes down with it.
- Who talks to whom — live TCP connections between your nodes reveal the real service dependencies, not the ones you think you have.
- Redundant pairs — two load balancers, two DB replicas. When one leg of a pair degrades, you know before the second one goes down too — Moniqo opens an incident the moment a pair is running without redundancy.
Anything the detection can't see, you can link by hand. The whole map is one click away from any node — and every alert carries this context with it.
Graceful degradation
Every server gets the monitoring it can support. Old machines aren't left behind — they just get simpler checks.
Old & limited servers
Legacy Linux, minimal tools. Still useful.
- Heartbeat
- Disk usage
- Inode usage
Modern Linux
systemd, proper filesystem, rich discovery data.
- Everything in Basic
- Service monitoring
- dmesg & OOM events
- Mount classification
Well-readable systems
AI-assisted role detection and smart suggestions.
- Everything in Standard
- AI role suggestions
- Smart mount selection
- Capability-aware upsell
Capability-aware add-ons
Advanced features are offered only when your server actually has the capabilities. We don't upsell features you can't use.
What data we collect — and why
Full transparency: here is everything the agent reads from your server, how often, and what problem each piece of data helps catch. Nothing else leaves the machine.
What we detect and notify
Every check below exists because it points to a real, actionable problem. If it can't tell you what to do about it, we don't alert on it.
Availability
- Node down — the server stopped reporting; you hear about it in minutes
- HTTP / TCP / ping monitors — external checks on your websites and services, from the outside in
Disks & storage
- Disk filling up — growth-based prediction: "full in ~N days". A stable disk at 90% stays quiet; static thresholds fire only as a last-resort safety net
- Inodes running out — same idea: "runs out in ~N days" prediction first, hard limits only as the final backstop
- Filesystem read-only — a mount flipped read-only, often a dying disk
- RAID degraded — the array lost redundancy
- Disk failed / degrading — SMART failure or growing error counts
- Mount missing from /etc/fstab — it won't survive a reboot
Services
- Service down — a monitored service stopped running
- Service flapping — repeated restarts, with the probable cause attached
- Running but disabled — works now, won't start after a reboot
Memory & CPU
- OOM kill — the kernel killed a process; we name the victim
- Memory pressure — PSI stall plus the biggest memory consumer
- CPU steal — an overcommitted hypervisor is stealing your cycles
Disk I/O
- I/O saturation — a disk ≥ 90% busy for 15 minutes, with the process to blame named in the alert
Kernel signals
Recognized dmesg signatures:
- NFS stall · disk I/O errors · filesystem errors
- Segfault · hung task · ECC / RAM errors
- CPU thermal throttling
Network & security
How reports read
No graphs. No dashboards to stare at. A Moniqo report is a sentence that tells you what's happening, why it matters, and what to do about it — and when we know the culprit, we name it. These are real notifications:
Service nginx is not running. It had been running without interruption since 2026-05-02 09:14 UTC (61 days). Check it with: systemctl status nginx
/var has used 92% of its inodes and at the current rate will run out in about 4 days. There's free disk space, but once inodes are gone no new file can be created and services start failing in confusing ways.
The kernel ran out of memory and killed mysqld. The process was using too much RAM (or something else starved it). Check what mysqld was doing and cap its memory or add RAM.
A disk has been 97% busy for the last 15 minutes — everything waiting on it is slow. The biggest disk user was rsync (210 MB/s).
The hypervisor is stealing 23% of this server's CPU time. The VM host is overcommitted — this slowness is not your server's fault.
Service moniqo-agent is running now, but it's disabled — it won't start automatically after a reboot. Enable it with: systemctl enable moniqo-agent
RAID array md0 is degraded — only 1 of 2 devices are active. The data currently has no redundancy: one more disk failure means data loss.
That's the whole product philosophy. Metrics exist so Moniqo can reason about your servers — you get the conclusion, in plain language, on the channel you already read.
Start with context. End with clarity.
Free for up to 5 nodes. Open source agent. One command to install.