Updated 2026-10-19

Memory alert in Telegram? Server memory 88%: is it a problem, and what to check

Got a memory alert in Telegram and want to know if it is real? This page shows how to judge it. To set up remote server alerts in Telegram and follow up from your phone, see Server alerts in Telegram.

Short answer: Memory usage of 88% on a Linux server does not prove a problem by itself, because Linux uses spare RAM for page cache. Check the available column in free -m, swap activity (si and so in vmstat 1) and the kernel log for OOM kills. Only low available memory together with active swapping or OOM kills points to real memory pressure.

Is 88% a problem? Look at available, not used

Linux keeps recently read files in memory (page cache, shown as buff/cache), because unused RAM does nothing. Most of that cache is given back when applications need memory, so a high "used" or "usage" percentage often just means the cache is full. Memory held in tmpfs or shared memory also counts as cache but cannot simply be dropped.

What matters is how much memory new work can still get without swapping. The kernel estimates that as MemAvailable, and free shows it as available. A monitoring tool may calculate its percentage from either figure, so check which one before reacting to a number such as 88%.

The commands below only read state. Run them on a server you are authorized to access.

How to judge it, step by step

1. Look at available memory

free -h

Read the available column of the Mem: row, not free or used. A low free value next to a large buff/cache is normal. Run it a few times over several minutes, or compare with your monitoring history: one sample does not show a trend.

2. Confirm with /proc/meminfo

grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree' /proc/meminfo

MemAvailable is the kernel's estimate of memory available for starting new applications without swapping; free reads its available column from here. SwapTotal: 0 kB means the server has no swap, so step 3 will always show zero and memory pressure shows up as OOM kills instead.

3. Check swap activity

vmstat 1 5

Ignore the first line: it is an average since boot. In the following lines, si and so are memory swapped in from and out to disk per second. Swap that is used but quiet (si and so at 0) is not a current problem. Swapping that keeps going while available stays low means the server is short of memory right now.

4. Check memory pressure (PSI), if your kernel has it

cat /proc/pressure/memory

On kernels with pressure stall information (Linux 4.20 and later, if enabled), the some line shows the share of time in which at least some tasks were stalled waiting for memory, averaged over 10, 60 and 300 seconds; full shows the share of time in which all non-idle tasks were stalled at once. Values that stay above zero mean memory is actually slowing work down. If the file doesn't exist, skip this step.

5. Find out who is using the memory

ps -eo pid,user,rss,comm --sort=-rss | head -n 15

RSS is resident memory in KiB. Shared pages are counted for every process that uses them, so the column can add up to more than the server's total. Use it to find the largest processes, then check whether they grow over time. In top, press Shift+M to sort by memory.

6. Look for OOM kills

sudo dmesg -T | grep -i -E 'out of memory|oom-killer|killed process' | tail -n 20
sudo journalctl -k --since "24 hours ago" | grep -i -E 'out of memory|oom-killer|killed process'

Out of memory: Killed process … lines mean the kernel had to kill a process to free memory; that is direct evidence of a memory shortage at that time. For containers, see Exit code 137 and OOMKilled.

Putting it together

Restarting a process, changing its memory settings, adding swap or moving to a larger server are changes; plan each one with a way to roll back.

A real case: what OpsMate recorded when a server's memory reached 88%

After launch, developers cannot always watch their servers. They need a useful signal when something changes: evidence of the anomaly, a notification, and a sensible next check.

This account comes from actual OpsMate (itops.sh) records in the Google Cloud test environment, managing a real server. Server, user and Telegram identifiers are omitted. It documents detection and notification—not a completed repair.

A patrol recorded a memory anomaly

On September 15, 2026, a patrol recorded CPU usage of 0%, memory usage of 88%, and disk usage of 64%. The memory check was classified as an anomaly with P2 priority. The 88% value is an observation from this event, not a universal alert threshold. A single sample does not establish a sustained condition.

High memory is not proof of a memory leak

The event did not contain available process-memory or heap-profile evidence. It does not establish which process was responsible or whether a leak existed.

The recorded recommendations included checking memory and inspecting the largest processes. These commands appeared as suggestions; the reviewed record does not show them being executed for this event:

free -m
ps -eo pid,rss,comm --sort=-rss | head

For developers, that turns a vague concern into a starting point for investigation. For experienced operators, the value is the timestamped evidence and explicit gaps—not a premature diagnosis.

Telegram sending was recorded, not human acknowledgement

The event timestamp was 07:32:35.788 UTC. The recorded Telegram send timestamp was 07:32:37.681 UTC, approximately 1.9 seconds later. The notification was categorized for human intervention, with a delivery status of sent.

This is evidence of a recorded successful send. It does not establish that a phone displayed the alert, that someone read it, or that an operator acted. It is not a notification-latency guarantee.

Was the issue fixed?

The reviewed event remained in an anomaly state and did not have a passed repair verification. We cannot describe it as a successful automatic repair or a confirmed recovery.

The next step is for the responsible operator to assess available memory, process usage and trends before deciding whether application, capacity or monitoring changes are appropriate. Changes still require risk assessment and verification.

Assistance without overstating autonomy

Early-stage developers need help noticing changes and organizing investigation. As systems grow, professional operators need less repetitive evidence gathering while retaining control over decisions.

The verified scope is narrow: a patrol detected a memory anomaly, created a problem, and recorded a Telegram notification plus suggested next checks. It does not establish a completed diagnosis or repair.

Start with one server, confirm the monitoring checks that fit it, and test that notifications reach your own phone. See the small-team VPS monitoring checklist.

Troubleshooting guides