About
ServerGuard exists because cPanel/WHM servers fail at 3am, and the people who can fix them at 3am are tired. Here is how the product got here and the principles it runs on.
The origin story
ServerGuard is built by a software house that has been managing websites and servers for hosting clients for years. We've lived this on-call rotation; this is the tool we wished we had.
We hit a stretch of production incidents. MariaDB crashes after OOM kills, CSF firewall conflicts blocking legitimate IPs, wp-login brute force from two attacker subnets we had been tracking, runaway PHP-FPM workers eating CPU, mailqueues backing up under sustained spam. Different symptoms, two things in common.
First, every one of them happened in the early hours of the morning. Second, every one of them was solvable in minutes by someone who already knew the stack, and cost hours when the on-call engineer had to context-switch from sleep, scroll through `journalctl`, and rebuild the diagnosis from scratch.
Who's building this
We are sysadmins and hosting operators. We have run cPanel/WHM in production for agency clients for years, across MariaDB upgrades, EasyApache rebuilds, Imunify360 deployments, and the regular rhythm of CSF rule changes and brute-force traffic. We've debugged the incidents this product is designed to handle, in production, at the time of day they actually happen.
The product is built by the same people who've been on call for it. We are not a generalist AI startup that picked servers as a market. We picked this market because we already work in it.
Human-in-the-loop is the product
ServerGuard is the diagnostic engine, not the final authority. The set of actions it can run on your server is a fixed list; anything destructive routes to a human.
Every action is risk-classified before it can run. Safe actions (read-only diagnostics, log fetches, status checks) execute autonomously. Moderate actions (service restarts, cache flushes) execute according to the policy you set per server. Dangerous actions (deletes, rebuilds, credential rotation) never auto-execute. They are routed to Telegram or the web dashboard for explicit approval before anything touches the box.
Every action is logged in an append-only audit trail with the exact command, the redacted output, and the reasoning that led to it. Reversible where the underlying operation allows it. Visible to anyone on your team with access.
When the diagnostic is uncertain, the alert says so, and the action queue escalates to a human. That precision is the core of the product.
Contact
Email is the primary channel.