Most people are, reasonably, wary of letting an AI model near their production server. Panelica's answer to that in OpsAI Sentinel (beta) is simple: the AI does nothing until something actually breaks, it defaults to read-only diagnosis, every action outside a tiny allow-list needs your one-click approval, and it runs under an AI account and server that belong to you — not Panelica's. This post explains exactly what Sentinel watches, what it is and is not allowed to do, and how to turn it on carefully.
Why "Only When Triggered"
An AI model that watches a server continuously would also bill you continuously, whether or not anything was wrong. Sentinel does not work that way. The part that runs 24/7 is ordinary Go code in the Panelica backend — it tails logs, checks service state, runs small probes every five minutes, and costs close to nothing to keep running. The AI agent itself only wakes up once a specific, configurable trigger fires: a service that stopped without a panel action, a fatal line in an nginx log, a certificate that failed to renew, disk usage past your own threshold. It investigates once, writes a report, and goes back to sleep. A typical investigation takes 20 to 60 seconds on whichever AI account you connected.
That design also answers the privacy question up front. Sentinel does not send your server, your logs or your configuration to Panelica at any point. The agent that reads the evidence and writes the report is the same AI agent you already installed and signed into inside OpsAI — Claude Code, Codex CLI, Gemini CLI or Cursor Agent — running under your own account, on your own server, under an isolated system user. Panelica does not provide an AI key, does not see the conversation, and does not bill you for any of it.
Which AI Agents Run Sentinel
Sentinel does not ship its own model. It hands each incident to whichever agent you already installed and signed into from OpsAI, the same coding agents you may already run on your own workstation:
- Claude Code — your Claude Code subscription or API key
- Codex CLI — your ChatGPT account or API key
- Gemini CLI — your Google account or API key
- Cursor Agent — your Cursor account
You can even assign different agents to different triggers — Claude Code for database incidents, Cursor Agent for everything else, for example. Agent installation itself has been tested across Ubuntu 22.04, 24.04 and 26.04, Debian 12 and 13, and AlmaLinux and Rocky 9/10.
What Sentinel Watches (40 Triggers)
Every trigger can be switched on or off individually, along with how many hits it needs, its time window, its cooldown, its severity and which OpsAI expert investigates it. Three presets exist — Silent (outages only), Balanced (recommended), and Everything — and editing a single trigger switches the profile to Custom without touching anything else you had configured.
Services
A monitored service (database, web server, PHP-FPM, mail, DNS, FTP) leaving the running state without a panel action; a managed Docker container stopping; failed systemd units, including ones the panel dashboard does not otherwise list, such as lxcfs, fail2ban or clamav.
Web servers
A fatal ([emerg]/[alert]/[crit]) line in the nginx error log for customer sites or for the panel itself; a burst of [error] lines (upstream timeouts, 502/504s) in a short window; the same class of fatal error in the Apache log; and an HTTP probe of every active domain that flags a site returning 5xx or timing out (off by default, to avoid noise on parked domains).
PHP
A PHP-FPM pool hitting max_children or failing to start; repeated PHP Fatal or Parse errors on one site — this one stays inform-only, since it is the site owner's own code.
Database
MySQL errors and crash signatures (a stopped signal, too many connections, InnoDB corruption); PostgreSQL PANIC or system-level FATAL errors.
Panel
A Go panic in the panel backend; a wave of backend or External API errors; scheduled cron jobs failing in a short window; the panel's own HTTPS port not answering; and a pending security-tagged package update — this last one is inform-only by design, Sentinel never applies an update automatically.
A wave of deferred outbound deliveries in the Postfix queue; a flood of failed IMAP/POP logins against mailboxes; the mail queue growing past your configured limit.
DNS
A BIND zone that failed to load; the server's own hostname no longer resolving (which breaks the panel's SSL and outbound mail HELO).
Resources
CPU, memory and disk warning and critical thresholds — the same thresholds you already set in Panel Settings → Monitoring; the kernel OOM killer firing; inodes running low even with free disk space; sustained high load average.
Backup, migration and SSL
A backup job failing, or no successful backup in longer than your configured window; a site migration pipeline step failing; a certificate close to expiry or failing to renew — the agent checks DNS and HTTP-01 reachability as part of the report.
Security (inform-only, always)
Malware detected by ClamAV; a brute-force wave (many IPs blocked in a short window); a wave of failed panel logins; a fail2ban ban wave. Every security trigger is capped at Inform only in the catalogue itself — there is no setting that lets a security trigger take an action, because an attacker could otherwise use the trigger to provoke one.
Three Modes: How Much Do You Let It Do?
| Mode | What the agent may do | What the panel does |
|---|---|---|
| Inform only (default) | Reads logs and server state through read-only commands and the panel API. Changes nothing. | If a panel action would help (restart or reload a service, clear temp files, vacuum the journal), the agent can only ask for it. You approve with one click; the panel applies it and verifies the result. |
| Safe actions | May request only the small set of allow-listed panel actions. | The panel itself executes and verifies each request — checking the service is active and the site responds — before reporting back. The agent never runs its own restart, delete or configuration command. |
| Full autonomy | Resolves the incident itself, with real shell access. | Recorded and reported, not executed by the panel. The prompt requires the least invasive step first (reload before restart), forbids deleting customer data or touching passwords, firewall or DNS, forbids applying package updates or rebooting, and requires the agent to verify before it reports success. Recommended only after you have watched the other two modes for a while. |
The allow-list the panel itself can execute is deliberately small: restart_service, reload_service (nginx, Apache and PHP only), clean_temp, and vacuum_journal. Anything else a report suggests — cleaning up orphaned files, for instance — shows up as a suggested step, and the incident view offers a button: Approve and let the agent do it. Only after you click it does the panel run that one follow-up investigation with full access, scoped to exactly the steps it already proposed and showed you.
How One Incident Actually Flows
Sample Reports From Real Test Runs
These three incidents were produced during development testing, with server and account names generalized below.
nginx fatal-error simulation — Cursor Agent, 23 seconds. Log line: bind() to 0.0.0.0:443 failed (98: Address already in use). The agent checked the actual state of the server: the nginx master process for customer sites was running, ports 80 and 443 were listening, and there was no live outage. It recommended no restart and downgraded the severity to informational — instead of treating a single alarming log line as an active incident.
12 failed systemd units. The agent found 11 orphaned Panelica application units left behind by deleted user accounts, plus the stock postfix@- template instance. It explained the root cause, confirmed the server was otherwise healthy, and proposed a cleanup — shown in the incident as suggested steps, with the "Approve and let the agent do it" button available if the operator wanted them applied.
Mail queue simulation — Claude Code, haiku-class model, 41 seconds. The report was written in the operator's own panel language (Turkish, in this run): "Postfix queue in a bad state: 412 messages queued against the 200-message alert limit…" — the same report, in whichever of the 31 supported languages your panel is set to.
Notifications: Bell, Telegram, Slack, Discord
Every report reaches the in-app notification bell. Sentinel also has its own Telegram tab right inside the OpsAI Sentinel settings: paste a bot token and a chat ID, save, send a test message, done — it creates a normal webhook subscribed to every Sentinel event, so retries and delivery logs live on the same Webhooks page as everything else. Slack, Discord and your own HTTP endpoints can subscribe to the same events from that Webhooks page. Messages are rendered as readable text in your panel's language, not a raw JSON dump — report, action taken, approval needed, failed run, daily briefing, agent offline, and budget reached each have their own notification.
Cost and Limits
- The agent never polls. It runs only when a trigger fires, plus an optional daily briefing.
- A daily run cap (off by default) stops new investigations once reached — incidents keep being recorded, just not analyzed, until the next day.
- Quiet hours defer non-critical incidents; critical ones still go through.
- A cooldown per trigger and per target prevents the same condition from re-firing repeatedly — and it survives a panel restart or an update, so applying a package update does not cause every probe-visible condition to fire again at once.
- The AI account is yours. Panelica does not provide an AI key and does not see your data.
Honest Beta Warning
How to Turn It On
OpsAI Sentinel lives in the bar at the bottom of the dashboard ("Sentinel on duty · your server is being watched"). Click it to expand, or go full screen. Before it can do anything you need an AI agent installed and signed in from the OpsAI screen — the same install flow used for OpsAI's terminal and Telegram features. Sentinel itself requires the ops_ai license feature; without it the tab shows as locked. Recommended first steps: pick the Balanced profile, leave the mode on Inform only, connect Telegram if you want alerts on your phone, and watch the Activity feed for a few days before considering Safe actions.
Frequently Asked Questions
What is OpsAI Sentinel in one sentence?
A beta Panelica feature that watches your server continuously for free and wakes an AI agent — running on your own account — only when a specific, configurable trigger fires, by default only to diagnose and report, never to act.
Does Sentinel send my server data to Panelica?
No. The AI agent that reads the evidence and writes the report is the same agent you signed in from OpsAI, running under your own account on your own server. Panelica does not receive the logs, the report, or the conversation.
What does Sentinel do by default when it detects a problem?
Nothing changes on the server. In the default Inform only mode the agent investigates with read-only commands, writes a plain-language report, and can only ask for an allow-listed action — you approve it with one click before the panel applies it.
Can Sentinel restart services or change configuration on its own?
Only if you raise the autonomy level. In Safe actions the panel itself executes a small allow-list of actions (service restart/reload, temp cleanup, journal vacuum) after the agent requests them, and verifies the result. In Full autonomy the agent can act directly, under rules that forbid touching customer data, passwords, firewall, DNS, package updates or reboots.
Does Sentinel apply security updates or touch Cloudflare automatically?
No to both. A pending security update only produces an inform-only notification — Panelica never applies a package update automatically, in any mode. Sentinel also does not trigger Cloudflare directly; the SSL-expiry trigger checks DNS and HTTP-01 reachability as part of its report, and if the agent has an OpsAI Cloudflare expert available it can diagnose and suggest a fix, but it does not change Cloudflare settings on its own.
Do security triggers (malware, brute force, login floods) ever take an action?
No. Every security trigger is capped at Inform only in the trigger catalogue itself — there is no configuration that lets one execute an action, so an attacker cannot use a security trigger to provoke a server change.
How much does Sentinel cost to run?
The 24/7 watching is ordinary backend code and costs close to nothing. The AI agent only runs on a real trigger, typically for 20 to 60 seconds, billed to whichever AI account you connected — not to Panelica. A daily run cap and quiet hours are available if you want a hard ceiling.
Which AI agents does Sentinel support?
Claude Code, Codex CLI, Gemini CLI and Cursor Agent — whichever you have installed and signed into from OpsAI. You can assign different agents to different triggers.
Is OpsAI Sentinel stable enough for production use?
It is labeled and treated as beta on purpose. The recommended path is Inform only for the first several days on a real server, reading every report, before considering Safe actions, and treating Full autonomy as something you grant only after that.
How do I turn OpsAI Sentinel on?
Install and sign into an AI agent from the OpsAI screen, then open the bar at the bottom of the dashboard and enable Sentinel. It requires the ops_ai license feature.