[sysx]
Features

Everything sysx tracks and does

Grouped the way the product is organised: inventory, maintenance, monitoring, AI assistance, and administration.

Inventory and accounts

  • Servers grouped by client. Each server carries role notes, OS, IP, and a plain-English description of what "normal" looks like on that machine.
  • Monthly hour budgets per server. For billing and for seeing where capacity is going.
  • Projects and client records sit alongside the server list, so the commercial context is next to the technical one.

Recurring maintenance

  • Reusable task types. SSL checks, backup verification, log rotation, failover tests, lockdown reviews, and others — each with a frequency set per server.
  • Scheduled generation and allocation. Tasks are generated on schedule and spread across the team weekly, capped per person so nobody is handed an impossible week.
  • Instructions, assignee, due date, status on every task.
  • A report against every task. Findings, an outcome (OK, issue found, escalated), and time spent — this is the audit trail.
  • Threaded comments on servers, tasks and clients, so working notes live next to the thing they describe.

Health monitoring

  • Two collection modes, so every box is covered: a small shell agent that pushes from cron (runs as root, so it can name the process behind each open port), and a PHP endpoint that gets polled over HTTPS for hosts already running a web server. No daemon, no agent framework, nothing beyond what a minimal Linux install already has.
  • What's collected: CPU load, memory, per-mount disk usage, and listening ports.
  • Port baselining. sysx builds a rolling baseline of which ports normally listen on each server, then notices when one stops — catching a service that died quietly, which is usually the failure that goes unseen longest.
  • Deterministic threshold checks, written in plain code: poll failure rates, disks projected to fill, sustained CPU, memory pressure. This is the authoritative layer, and it cannot be talked out of firing.

AI assistance

  • Scheduled estate review. Reads the collected data and posts a short written summary to the team chat several times a day. It reports what the telemetry says, and stays quiet when there is nothing to report.
  • Chat assistant. Ask it about the current state of any server, what a reading means, or for help with Linux commands and maintenance work. It reads live telemetry, the maintenance record, and the team's recorded notes.
  • Written knowledge base. The assistant maintains durable facts about the estate that telemetry can't show — non-standard ports, role changes, work left half finished. Everything it records is reviewable and correctable by an admin on a dedicated page.
  • Standing server summaries. A plain-English summary of each server, regenerated only when something about that server has actually changed. Useful to the assistant, and useful to a human picking up an unfamiliar machine.
  • Configurable model choice. The routine analysis is designed to run on inexpensive models, so running costs stay low.

Administration

  • Two roles: sysadmin and admin.
  • Settings for team workload limits, and for how much history the AI features carry.
  • Self-hosted throughout. Your data stays on your server.

Want to see how it fits your estate?

Tell us how many servers you look after and who looks after them, and we'll take it from there.

Enquire about a deployment