Published Feb. 15, 2026
Memory graphs are easy to set up and surprisingly easy to get wrong. A line that slowly climbs for two weeks looks fine until the day it crosses a limit nobody chose carefully, and the alert arrives at the worst possible time.
Part 1 of this list covered what to measure. This second list is about what surrounds the measurement: the baselines, limits, and habits that decide whether your memory monitoring helps your team or just adds another graph nobody opens. The seven checks below pick up where Part 1 stopped.
A web server, a database, and a cache all use memory differently, and some are meant to use most of what they have. Before setting any limit, look at a typical week for each server. Without that baseline, a threshold is a guess, and guesses are why alerts end up either constant or silent. Write the baseline down somewhere your team can find it, so the next person adjusting a limit isn't starting from nothing.
A single limit leaves you with one moment to react, and it's usually the worst one. A warning level tells you memory is climbing while there's still time to investigate. A critical level tells you to act now. Check that both exist and that the gap between them gives your team a realistic window to respond. If the gap is so small that warning and critical fire minutes apart, the warning isn't doing its job.
Memory can jump briefly during a deployment, a restart, or a heavy job and then settle. An alert that fires on every jump trains people to ignore it. A short delay before the alert, so only sustained high usage notifies anyone, keeps the signal useful. The right delay is usually short, long enough to skip a restart but short enough that a real problem still reaches someone quickly.
Teams sometimes fix memory trouble by restarting a service, which resets the graph and hides the cause. If memory climbs back to the same level after every restart, that's a pattern worth investigating rather than a one-time fix. Compare usage across several days, not just since the last restart. A graph that shows a neat sawtooth shape, climbing and dropping at each restart, is often a leak that someone has learned to live with.
An alert is only as good as the person who sees it. Check that memory alerts for each server reach the team responsible for it, not a shared inbox that everyone skims. Production and test servers usually deserve different destinations, and it's worth re-checking routing whenever people change teams.
When memory drops back to a healthy level, someone should know. Without a recovery notice, people keep checking a dashboard to see whether the fix worked, or assume the problem is still open. A clear all-clear closes the loop.
Alerts catch emergencies, but history shows whether a server is the right size. A machine that never uses half its memory may be oversized, and one that regularly runs near its limit needs attention before the next incident. Set a regular time to look at the trend, even when nothing has fired.
Start with the servers you can least afford to lose. Check that each one reports memory, that its limits reflect its own baseline, and that its alerts reach a person who can act. Then look at your tooling against that list: can it separate warning from critical, delay noisy alerts, route by owner, and confirm recovery?
Be wary of any setup that looks complete but hasn't been tested. Trigger a test alert and watch where it lands. Also consider how much effort it takes to maintain. A setup that needs manual attention every time you add a server tends to fall behind, and the servers that fall behind are usually the ones nobody remembers to check.
BigBell handles the parts of this list that match its actual features. For Linux servers, an installed agent reports memory used, available, and total, along with the percentage in use, and it reports CPU and disk alongside it. Thresholds are set per resource with separate warning and critical values, so each server can have limits that suit its role.
A configurable delay filters out brief spikes. Alerts can be routed at the organization, project, or application level and delivered by email, Slack, Microsoft Teams, Google Chat, WhatsApp, SMS, or a phone call, and a recovery notification is sent when a resource returns to normal. More detail is on the BigBell monitoring page.
Memory rarely misbehaves alone. The CPU utilization monitoring refresh and the disk space monitoring checklist cover the other two numbers worth watching on the same server, and the Linux server monitoring guide shows how they fit together.
What's a safe memory usage level? It depends on the server. Some workloads are designed to use most of their memory, while others should stay well below it. Use each server's own history to decide what's normal.
Why not just alert at one fixed percentage? One limit gives you a single moment to react. Separate warning and critical levels give you time to investigate before the situation becomes urgent.
How does a delay help with memory alerts? It means memory has to stay high for a short time before anyone is notified. Brief spikes from restarts or jobs pass without waking anyone, while sustained problems still alert.
What does BigBell report for memory on Linux servers? Memory used, available, and total, plus the percentage in use, sent by the installed agent alongside CPU and disk readings.
Should every server share the same memory threshold? No. A database and a lightweight service behave differently, so each needs limits based on its own baseline.
How often should I review memory trends? Regularly, even without alerts, for example monthly. Trends show whether a server is oversized or heading toward its limit.
What should I check first when a memory alert fires? Look at what changed recently, such as a deployment or a restart, then check whether usage is still climbing or has levelled off. Looking at CPU and disk on the same server helps rule out related causes.
Is high memory usage always a problem? No. Many applications deliberately use available memory, so a high reading isn't automatically bad. It becomes a concern when it's unusual for that server or keeps climbing without levelling off.
How long should I keep memory history? Long enough to see patterns across weeks, not just days. A longer view makes slow growth much easier to spot than a short window does.
Who should receive memory alerts? The team that owns the server and can act on the alert. Sending everything to one shared place makes alerts easy to ignore.
Can I get help setting this up? Yes. You can contact the BigBell team with questions about your own setup.
Ready to try it on your own servers? Try BigBell free.
