All docs
Getting started
What Opservo is
This page gives you the one-paragraph answer to "what is Opservo", the handful of words you will meet in the dashboard, what the agent finds on a server without any configuration, which platforms it runs on, and how data gets from your server to your screen.
Opservo is an AI infrastructure monitoring and remediation platform for Linux servers. One Go agent installs with a single command, opens no inbound ports and is read-only by default. Within a few minutes it inventories every service, container, app, domain, port and log source on the box, scores the server 0–100, explains each problem in plain English and gives you the exact command that fixes it. Around the agent sit external uptime checks, alert routing, on-call escalation, incident management and public status pages.
The words you will meet
| Term | What it means |
|---|---|
| Workspace | Your account’s container for servers, users, channels and billing. A server reports to exactly one workspace. |
| Server | One Linux host running the Opservo agent. It appears as a card on the fleet grid and has its own page. |
| Health score | A deterministic 0–100 number per server. Every point lost is attributed to a named rule with a threshold, the current value and a fix. See Health score. |
| Finding | One thing that needs attention, ranked critical, warning or info. Each carries a cause and a runnable fix command. |
| Alert | A critical finding or external check failure delivered to a notification channel (Slack, Discord, Telegram, email, webhook, PagerDuty, OpsGenie). See Alerts and channels. |
| Uptime monitor | An external HTTP, TCP, ping, DNS, domain or heartbeat check that runs from Opservo’s side, so it still works when the server is fully down. See Uptime monitors. |
| Remote actions | A per-server switch, off by default, that lets the dashboard run commands on the box. See Remote actions. |
| AI chat | A chat grounded in your live server data. It answers "why is this server slow?" with evidence. Each answer uses AI credits included in your plan. See AI chat. |
What the agent discovers by itself
There is no configuration file. On every heartbeat the agent collects the facts below and the dashboard builds the server page from them. Anything that is not present on the host is simply skipped.
| Area | What is collected |
|---|---|
| System | OS, kernel, uptime, CPU use, load, I/O wait, CPU steal, memory and swap, memory pressure, per-mount disk use, open file descriptors, zombie and blocked processes |
| Storage | Inode exhaustion, read-only remounts, SMART and SSD-wear where smartctl is installed |
| Workloads | systemd units, Docker containers with live resource use, PM2 processes, running processes |
| Apps | Laravel, WordPress, PHP, Node.js, Next.js, Vite dev servers, Django, FastAPI, Flask, Rails and Go apps, with the git branch and commit they run from |
| Network | Listening ports mapped to their process, interface errors, TCP retransmits |
| Domains | nginx and Apache virtual hosts with live SSL certificate expiry |
| Logs | nginx, Apache, Laravel, Docker, PM2 and the systemd journal, clustered into patterns (raw lines are never stored) |
| Web traffic | Request rate and status-code breakdown parsed from access logs |
| Data stores | MySQL, Redis and PostgreSQL configuration, connections, slow queries and cache hit rates |
| Security | Database ports exposed to the internet, failed SSH logins, root login, firewall state, suspicious processes, recent logins, unscoped passwordless sudo, SSH authorized keys (key type and comment only) |
| Reliability | OOM kills, kernel panics, segfaults, filesystem and disk I/O errors from the kernel log |
| Maintenance | Pending OS package updates and security patches, reboot required, installed packages, language runtimes and versions |
| Scheduled | cron jobs and systemd timers |
| Configuration | NTP time sync and whether swap is configured |
Supported platforms
- •Linux only, on
amd64(x86_64) orarm64(aarch64). Bare metal, VMs and cloud instances all work. - •Any distribution that runs systemd. Ubuntu, Debian and the RHEL family are the common cases. Package-update facts are richest on Debian and Ubuntu.
- •Root or
sudois required to install the system service, so shared hosting plans (cPanel and similar) are not supported. Add those sites as an uptime monitor instead. - •Kubernetes clusters use a separate read-only in-cluster collector, installed with one
kubectl apply. See Kubernetes.
How data flows
- 1.The agent runs as a systemd service and collects a snapshot every 60 seconds.
- 2.It sends the snapshot to
api.getopservo.comover outbound HTTPS on port 443. Nothing connects in to your server; there are no inbound ports. - 3.Every payload is HMAC-signed with a secret issued at registration. The API rejects unsigned or altered payloads.
- 4.If the API is unreachable, snapshots are buffered locally for up to 24 hours in
/var/lib/infrapilotand sent when the connection returns. - 5.Once an hour the agent checks for a new build and only installs one whose manifest carries a valid Ed25519 signature. See Agent updates.
- 6.On the dashboard, a server whose last heartbeat is older than three minutes shows as offline.
Ready to try it? Install the agent takes about 30 seconds.
Last updated 2026-10-01. Found a mistake? Email hello@getopservo.com.