# Memory leaks, out-of-memory kills and filling disks > Some problems look fine every time you look. Memory sits at 60% today and 64% tomorrow, and the restart on Sunday puts it back to 30%. Source: https://infranest.io/docs/slow-trouble Last updated: 2026-11-02 --- This article is for anyone who has noticed a server "looking fine" even though something slow and quiet is going wrong underneath — memory that creeps up, a process that gets killed, or a disk that's filling up a little more every day. ## Overview - InfraNest watches for slow-building problems that don't show up if you only glance at a server once — and warns you before they cause an outage. - This needs the agent installed on the server, since these readings only exist on the machine itself. - Each issue stays visible until it's actually resolved. You can snooze it or mark it as expected, and it will be set aside on the server's page too. ## Where you see them - On **Home**, under what needs you. - At the top of the **server's page**, with a button that takes you to what to look at. - On the **Volumes** page and the volume's own page, for a volume that is filling up. - In the **Servers** overview, as a cause with the servers it affects. ## Spot a memory leak A memory leak looks like memory climbing steadily — maybe 5% a day — and only dropping back down when the server restarts. Because of that, the server can seem fine for days at a time before the climb starts again. > [!NOTE] > We only flag this after seeing it happen on at least two runs of the server in a row, with memory dropping at the restart in between. One climb on its own isn't enough — it could just be a busy week. 1. Click **Open the workload** to go to the server's **Workloads** tab, which jumps straight to the service or container whose memory keeps growing, along with its processes. 2. Fix it there if you can — often an update is all it takes. Until then, restarting just that service on a schedule (for example, overnight) buys you time without restarting the whole server. If no single workload stands out, the message will say so, and **Open memory chart** shows exactly when the climb started. ## Handle processes killed for lack of memory When a server runs out of memory, the system stops a process to free some up. Whatever that process was doing ends abruptly, and the server often looks fine again right afterward — because the memory has just been freed. This message appears when three or more processes have been killed this way in the last seven days. 1. Click **See what uses memory** to open the **Workloads** tab, which lists what's using the most memory and what has been growing. 2. Give that service a memory limit, or give the server more memory overall. > [!TIP] > If you want to be alerted the moment a single process is killed, turn on **The server ran out of memory** under alert defaults. ## Fix a disk or volume that's about to fill up When a disk keeps filling at a steady rate and will be full within two weeks, it gets listed. If that disk is a cloud volume, the message appears on the volume, since the volume is what you can grow. Otherwise it appears on the server. 1. If it's a volume, open it and choose **Grow the volume**. 2. If it's on the server itself, clear out what's filling it — old logs and backups are the usual culprits. ## Fix a disk running out of inodes Every file on a disk uses one inode, and most disks only have a fixed number of them. A disk full of small files — a cache, a mail queue, PHP sessions — can run out of inodes while it still shows plenty of free space. Once that happens, nothing new can be saved, and programs start failing. It's listed on the server when a disk will run out of inodes within two weeks at its current rate, or immediately once 95% of them are used. The same information appears on the disk's line on the server's **System** tab. 1. Find the folder with the most files and clear out what's no longer needed. 2. Look first at old sessions, cache files, and any stuck mail queue — these are the usual causes. > [!TIP] > A bigger disk helps less than you'd expect here — what usually fixes an inode problem is fewer files, not more space. ## Tips - It's a rate, not a prediction: InfraNest measures how the last few days actually went and projects where that leads. A server that changes what it's doing won't necessarily follow the trend. - Most servers never show any of this. If a reading is flat, jumps once and settles, or just bounces around, nothing is reported rather than guessing. - A server you've only just started watching has too little history for an opinion — a memory leak needs at least two restarts within the last 30 days before it can be identified. ## Troubleshooting - **Nothing shows for a server you know is leaking:** check that the agent is installed and reporting, on the server's **System** tab. Memory readings need the agent. - **The workload isn't named:** the **Workloads** tab needs about two days of readings before it can tell which service is actually growing.