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
See the warning signs. Act before it's too late.
Monitor your Linux infrastructure, identify suspicious activity, and investigate incidents from one centralized dashboard — giving administrators the visibility to act before manageable problems escalate.
- Read-only agent, runs as an unprivileged user
- No remote commands, no automatic “fixes”
- Two-factor sign-in for every account
- Security findings close only after human review
Platform
One view of every Linux server you look after.
Health, incidents and security findings, organised the way hosting and infrastructure teams actually work. Every clip below uses demo data.
Metric history
Charts from the last hour to the last 30 days, so you can see exactly when conditions changed.
See it in the tourIncidents & Slack routing
Duration, recovery and cooldown rules, and one timeline showing where each Slack alert went. Email alerts are planned.
How alerting worksSecurity findings
Miners, reverse shells, rootkit signs and persistence — with secrets masked in the evidence and a person reviewing every finding.
What it detectsClients & routing
Client folders with their own Slack channels. Operators organise servers; only admins decide where alerts go.
See it in the tourDiscovery & panel versions
OS, kernel and services detected automatically, with cPanel, Plesk and Proxmox versions checked against current releases.
Read the FAQ- Offline detection
- Viewer · operator · admin roles
- Audit log
- Two-factor sign-in for every account
- Read-only, unprivileged agent
Compromise detection
Catch the foothold before the damage.
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.
- No delayA finding alerts on the first agent report, ahead of every other notification.
- Can't be mutedIt goes to the client's channel and the default channel, even when a server's Slack is turned off.
- Never closes by itselfEach finding stays open until a person reviews it. Only an admin can mark a critical finding as expected.
#northwind-alerts · #ops01:42
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
criticalReverse shellbash -i >& /dev/tcp/…
criticalNew administrator“deploy” added to sudo
warningLogin from a new networkroot · 192.0.2.0/24
critical/etc/ld.so.preloaduser-space rootkit sign
warningCron file changed/etc/cron.d/sysupdate
What ServerOps checks — and what it doesn't.
Checks
- Crypto-miner processes and mining-pool arguments
- Reverse shells and processes disguised as kernel threads
- Rootkit indicators: /etc/ld.so.preload, known rootkit modules, SUID files in temp directories
- File and process indicators of selected known malware families
- New administrators, extra root accounts and new login accounts
- Cron, startup, PAM and udev changes; new listening ports
- Logins from networks a user hasn't used before
Doesn't
- Run commands, kill processes or remediate anything
- Run as root — so no SSH auth-log analysis, sudoers rules or system-binary integrity checks
- Guarantee detection of every attack, malware variant or ransomware strain
- Replace an EDR — it is an early-warning layer
Ransomware risk
Flags the footholds that often come first: backdoors, persistence and new admin access. Not a prevention guarantee.
Crypto-mining malware
Known miner names, stratum arguments and outbound connections to common pool ports.
Reverse shells & backdoors
/dev/tcp, nc -e, socket one-liners, and backdoor process look-alikes.
Persistence
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
From early warning to informed action.
- 01 · Detect
A signal crosses a line
A configured threshold is breached, a server stops reporting, or the agent reports a security finding.
- 02 · Evaluate
Rules decide if it matters
ServerOps applies severity, duration, recovery and routing rules. Security findings skip the delay and alert straight away.
- 03 · Notify
The right channel hears it
Notifications go to the configured Slack channel and appear in the dashboard with full context.
- 04 · Act
Your administrator decides
Your team investigates and carries out the fix. ServerOps never changes a monitored server.
Product tour
Explore each view yourself.
The same five views as the walkthrough, one at a time. Everything shown uses demo data.
Fleet overview
Servers grouped by client and category, worst first, with a health summary, fleet averages, open security findings and recent activity. Filter by health or category, or search by name or IP.
Server details
System facts, current values and filesystems, then history charts for CPU, memory, load, disk and network from 1 hour to 30 days. The server's incidents and settings are one tab away.
Incidents
Each incident keeps its alert values, a snapshot of what was running when it fired, and every Slack message it sent — opened, and later recovered.
Security findings
Findings show their evidence, with secrets masked, and what to check first. They never close on their own: someone marks each one resolved or expected, with a note kept in the audit log.
Clients & routing
Client folders hold their servers, open incidents and Slack channel. Admins decide where alerts go; operators organise folders and categories.
Already a user? Sign in to the dashboard
Who it's for
Built for the people behind the servers.
Linux administrators
One view across mixed fleets instead of a dozen SSH sessions.
Hosting providers
cPanel, Plesk, web, database and mail hosts, grouped by category.
MSPs
Client folders, each with its own Slack channel.
Infrastructure teams
Trends, incidents and availability, with roles and mandatory 2FA.
About
Evidence for administrators, not another tool that touches production.
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
Questions, answered.
What is ServerOps?
A centralized monitoring and compromise-detection platform for Linux servers, built for administrators who look after a single fleet or many clients' servers.
Does the agent change my 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.
Can it detect ransomware or every malware infection?
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.
Where do alerts go?
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.
Does it fix incidents automatically?
No. ServerOps focuses on detection, alerting and investigation context. Corrective action stays with your administrators.
How do I try it?
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
Get early access to ServerOps.
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.