{"slug": "what-happened-in-3-days-of-letting-ai-manage-my-server", "title": "What Happened in 3 Days of Letting AI Manage My Server", "summary": "A developer's AI system autonomously managed a home server for three days, identifying and fixing multiple issues without human intervention. The AI detected a false positive in container monitoring caused by the monitoring script itself exceeding OpenSSH's connection limit, then automatically implemented a fix by switching from parallel to sequential SSH connections and adding retry logic. During nightly patrols, the AI also discovered a 21.3GB Nextcloud log file that had stopped rotating and identified 1,241 SELinux denials wasting CPU resources, flagging problems the developer said they would never have noticed on their own.", "body_md": "In my [previous article](https://dev.to/quolu/delegating-full-server-management-to-ai-111f), I wrote about delegating the entire management of my home server to an AI. The system is designed so that the AI performs patrols late at night, and during the day, it springs into action if monitoring scripts detect any anomalies.\n\nI explained how I built the system. Now, I will write about what actually happened after putting it into operation for three days.\n\nOn the morning of the third day of operation, the monitoring script detected an anomaly: the `license_api_prod`\n\ncontainer was not responding.\n\nThe AI went into action and began its investigation. It connected to the server via SSH and checked the status of the container. The result—**the container was running perfectly fine.**\n\nIt was a false positive. Furthermore, two minutes later, the same false positive occurred for `ddnser`\n\n.\n\nThe cause identified by the AI was as follows.\n\nThe monitoring script checks the server status every 60 seconds. It opens three connections for system resources (disk, memory, swap) and up to nine for health checks of the seven containers. It was opening a total of over 10 SSH connections **simultaneously**.\n\nOpenSSH has a setting called `MaxStartups`\n\n, which limits the number of simultaneous connections. The default is 10. The monitoring script was exceeding this limit, causing connections to be rejected. In other words, **the monitoring script itself was putting a load on the server, causing its own SSH connections to fail.**\n\nThe AI changed the execution method for health checks from full parallelization using `Promise.allSettled()`\n\nto sequential execution using `for...of`\n\n. Now, only one SSH connection is open at a time.\n\nEven when run sequentially, temporary SSH disconnections can occur. A connection might drop once due to server load or a momentary network glitch.\n\nFollowing the second false positive two minutes later, the AI added a helper function to identify \"SSH transport errors.\" It detects patterns such as `Connection closed`\n\n, `Connection refused`\n\n, and `ETIMEDOUT`\n\n, waits for three seconds, and then retries once. It only reports an anomaly if the connection fails again after the retry.\n\n**The fix was two-pronged: reducing the number of SSH connections by moving from parallel to sequential, and handling temporary disconnections with retries.** Both were done without human intervention. I just received a notification on Discord saying \"Fixed,\" and that was it.\n\nEvery day at 4:00 AM, the AI patrols the entire server. It checks security settings, resource usage, container configurations, and log contents. The AI looks at parts that humans usually do not check daily.\n\nDuring the patrol on the second day of operation, the AI noticed an anomaly in the Nextcloud log file.\n\n`/var/mnt/nextcloud_data/nextcloud.log`\n\n— **21.3GB.**\n\nThe log file had ballooned to 21GB. Because it was on NFS, there was no disk space crisis, but log rotation was not functioning. I would never have noticed this on my own.\n\nThere was another issue. SELinux was denying lock access to the `auction.db`\n\nfor the auction-bot every minute. 1,241 instances in the past 24 hours.\n\nSELinux runs in Permissive mode, so the action was not actually blocked. The application ran normally. However, every time a denial occurred, a daemon called `setroubleshoot`\n\nwould start to analyze it, temporarily consuming 22.9% of CPU.\n\nThere was no actual damage, but it was wasting resources. I don't think I would have ever found this if the AI hadn't flagged it.\n\nThe patrol surveys the entire server every day. The AI determines what to look for, but as a result, trends emerge over time.\n\n| Date | Swap Usage | Note |\n|---|---|---|\n| 4/2 | 89% | |\n| 4/3 | 92% | Slight upward trend |\n| 4/4 | 62% | Reset by server reboot |\n\nThe AI tracked the trend of swap usage building up day by day. The server was rebooted and reset on 4/4, but swap might become critical during long periods of operation without a reboot. The AI writes \"Continued monitoring required\" in its report every time.\n\n| Date | Currently Banned | Total BANNED |\n|---|---|---|\n| 4/2 | 14 IPs | 235 |\n| 4/3 | 10 IPs → 14 IPs | 242 → 293 |\n| 4/4 | 8 IPs | — |\n\nBrute-force attacks against SSH occur daily. Connection attempts using common usernames such as `admin`\n\n, `ubuntu`\n\n, and `mysql`\n\n. fail2ban bans them calmly. Password authentication is disabled and only key authentication is used, so they are not broken through, but I want to be aware that the attacks are occurring. The AI reports this daily in its report.\n\nLooking back at what happened over the three days, most of the issues the AI dealt with were things I could not have noticed myself.\n\nHitting the limit for SSH connections. The Nextcloud log ballooning to 21GB. SELinux denial logs piling up every minute. Swap becoming critical day by day. None of these would be visible unless a human specifically opened the logs to check.\n\nWhile I am asleep, the AI watches the server, and when I wake up, the results are waiting on Discord. It fixes problems if it can, and reports them if it can't. After running it for three days, I feel this system works even better than I expected.", "url": "https://wpnews.pro/news/what-happened-in-3-days-of-letting-ai-manage-my-server", "canonical_source": "https://dev.to/quolu/what-happened-in-3-days-of-letting-ai-manage-my-server-2ch0", "published_at": "2026-05-30 00:53:36+00:00", "updated_at": "2026-05-30 01:12:08.063140+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure"], "entities": ["OpenSSH"], "alternates": {"html": "https://wpnews.pro/news/what-happened-in-3-days-of-letting-ai-manage-my-server", "markdown": "https://wpnews.pro/news/what-happened-in-3-days-of-letting-ai-manage-my-server.md", "text": "https://wpnews.pro/news/what-happened-in-3-days-of-letting-ai-manage-my-server.txt", "jsonld": "https://wpnews.pro/news/what-happened-in-3-days-of-letting-ai-manage-my-server.jsonld"}}