Linux 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.

34-second walkthrough, no sound, demo data: the fleet overview, a server's load history, an incident timeline with its Slack delivery, reviewing a security finding, and client folders with their Slack channels.

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.

Fleet overview

Every server grouped by client and category, worst first, with CPU, memory, load and disk at a glance.

See it in the tour

Metric history

Charts from the last hour to the last 30 days, so you can see exactly when conditions changed.

See it in the tour

Incidents & Slack routing

Duration, recovery and cooldown rules, and one timeline showing where each Slack alert went. Email alerts are planned.

How alerting works

Security findings

Miners, reverse shells, rootkit signs and persistence — with secrets masked in the evidence and a person reviewing every finding.

What it detects

Clients & routing

Client folders with their own Slack channels. Operators organise servers; only admins decide where alerts go.

See it in the tour

Discovery & panel versions

OS, kernel and services detected automatically, with cPanel, Plesk and Proxmox versions checked against current releases.

Read the FAQ

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
Demo data

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.

  1. 01 · Detect

    A signal crosses a line

    A configured threshold is breached, a server stops reporting, or the agent reports a security finding.

  2. 02 · Evaluate

    Rules decide if it matters

    ServerOps applies severity, duration, recovery and routing rules. Security findings skip the delay and alert straight away.

  3. 03 · Notify

    The right channel hears it

    Notifications go to the configured Slack channel and appear in the dashboard with full context.

  4. 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. Filter by health, category or client, or search by name or IP.

Fleet overview8 servers · 3 clients

Northwind Hosting · Web

● web-01
203.0.113.21
CPU 12%Mem 48%Disk 61%
◆ web-02
203.0.113.22
Load 7.9 / 4 coresfor 11 min

Acme Retail · Database

● db-01
198.51.100.40
CPU 31%Mem 71%Disk 44%
● db-02
198.51.100.41
CPU 18%Mem 66%Disk 39%

Demo data — fictional clients, documentation IP ranges.

Server details

System facts, current values, filesystems and history charts for 1 hour to 30 days, plus the server's recent incidents and settings.

web-02 · Ubuntu 24.04 · 4 coreslast 24 h
Load per coreCPUWarning threshold

Demo data.

Incidents

Each incident keeps its timeline: when the alert opened, where the Slack message went, and when the condition recovered.

High load · web-02Resolved
  1. Load per core above 1.5Warning threshold breached
  2. Alert openedCondition held for the configured 5 minutes
  3. Slack · #northwind-alertsDelivered via client folder channel
  4. RecoveredBack under threshold; incident resolved and kept in history

Demo data.

Security findings

Findings show their evidence (with passwords and tokens masked) and first-response steps. They never close on their own: someone reviews each one.

Crypto-miner · app-07critical
process xmrig · args: -o stratum+tcp://pool.example:3333 --donate-level 1
Mark resolvedMark expected (admin)

Demo data. Buttons are illustrative.

Clients & routing

Client folders hold their servers, open incidents and Slack channel. Admins decide where alerts go; operators organise folders and categories.

Demo client folders
Client folderServersOpen incidentsSlack channel
Northwind Hosting41#northwind-alerts
Acme Retail30#acme-ops
Internal10default channel

Demo data.

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.