Fleet overview
Every server grouped by client and category, worst first, with CPU, memory, load and disk at a glance.
See it in the tourLinux monitoring · compromise detection
Monitor your Linux infrastructure, identify suspicious activity, and investigate incidents from one centralized dashboard — giving administrators the visibility to act before manageable problems escalate.
Platform
Health, incidents and security findings, organised the way hosting and infrastructure teams actually work. Every clip below uses demo data.
Every server grouped by client and category, worst first, with CPU, memory, load and disk at a glance.
See it in the tourCharts from the last hour to the last 30 days, so you can see exactly when conditions changed.
See it in the tourDuration, recovery and cooldown rules, and one timeline showing where each Slack alert went. Email alerts are planned.
How alerting worksMiners, reverse shells, rootkit signs and persistence — with secrets masked in the evidence and a person reviewing every finding.
What it detectsClient folders with their own Slack channels. Operators organise servers; only admins decide where alerts go.
See it in the tourOS, kernel and services detected automatically, with cPanel, Plesk and Proxmox versions checked against current releases.
Read the FAQCompromise detection
Ransomware and data theft rarely start loud. They start with a miner, a backdoor or a changed cron line. ServerOps watches for those footholds — and treats them as the most urgent thing on your screen.
CRITICAL · SECURITY FINDING
Crypto-miner on cp-01
user www-data · /tmp/.x/xmrig
-o stratum+tcp://pool.example:3333 -u ●●●●●●
First-response steps included · awaiting review
Flags the footholds that often come first: backdoors, persistence and new admin access. Not a prevention guarantee.
Known miner names, stratum arguments and outbound connections to common pool ports.
/dev/tcp, nc -e, socket one-liners, and backdoor process look-alikes.
Malicious cron lines, startup scripts, systemd units, udev rules and PAM changes.
Indicator sets include perfctl, Kinsing, BPFDoor, Plague, Koske, Auto-Color, sedexp, XorDDoS and RedTail, drawn from published security research.
How it works
A configured threshold is breached, a server stops reporting, or the agent reports a security finding.
ServerOps applies severity, duration, recovery and routing rules. Security findings skip the delay and alert straight away.
Notifications go to the configured Slack channel and appear in the dashboard with full context.
Your team investigates and carries out the fix. ServerOps never changes a monitored server.
Product tour
The same five views as the walkthrough, one at a time. Everything shown uses demo data.
Servers grouped by client and category, worst first. Filter by health, category or client, or search by name or IP.
Northwind Hosting · Web
Acme Retail · Database
Demo data — fictional clients, documentation IP ranges.
System facts, current values, filesystems and history charts for 1 hour to 30 days, plus the server's recent incidents and settings.
Demo data.
Each incident keeps its timeline: when the alert opened, where the Slack message went, and when the condition recovered.
Demo data.
Findings show their evidence (with passwords and tokens masked) and first-response steps. They never close on their own: someone reviews each one.
Demo data. Buttons are illustrative.
Client folders hold their servers, open incidents and Slack channel. Admins decide where alerts go; operators organise folders and categories.
| Client folder | Servers | Open incidents | Slack channel |
|---|---|---|---|
| Northwind Hosting | 4 | 1 | #northwind-alerts |
| Acme Retail | 3 | 0 | #acme-ops |
| Internal | 1 | 0 | default channel |
Demo data.
Already a user? Sign in to the dashboard
Who it's for
One view across mixed fleets instead of a dozen SSH sessions.
cPanel, Plesk, web, database and mail hosts, grouped by category.
Client folders, each with its own Slack channel.
Trends, incidents and availability, with roles and mandatory 2FA.
About
ServerOps is built around one principle: the people responsible for servers need timely visibility and useful evidence — and should stay in charge of every change.
That is why the agent is read-only and unprivileged, the central server can't send it commands, and every security finding waits for a person to review it.
Recognise warning signs early, understand what needs attention, and give administrators the context to act.
FAQ
A centralized monitoring and compromise-detection platform for Linux servers, built for administrators who look after a single fleet or many clients' servers.
No. It runs as an unprivileged user, only reads system information, and accepts no commands from the central server. ServerOps reports; your team decides.
No tool based on indicators can promise that. ServerOps checks selected indicators — miners, backdoors, persistence, rootkit signs and known malware families — that often appear before or alongside serious attacks.
To Slack and the dashboard. Each server follows its own setting, then its client folder's channel, then the default channel. Security findings also go to the default channel and ignore a server's “off” setting. Email notifications are planned.
No. ServerOps focuses on detection, alerting and investigation context. Corrective action stays with your administrators.
Email us using the button below with a rough idea of how many Linux servers you manage. Early access is being opened gradually.
Early access
Tell us roughly how many Linux servers you look after and what you run on them.
Email us to request access Opens your email app. We reply by email; nothing is stored on this website.