"The server is slow" is the most common and least useful complaint in IT. Slow for whom, since when, doing what? Live performance history answers all three - if you read it in the right order.
Without data, a slow server means an afternoon of guessing and random restarts. With a monitoring history - the kind ManageEngine Applications Manager keeps - the same complaint takes fifteen minutes: you compare now against normal and find which resource broke pattern first. This page gives the order to work in, from most to least common cause.
The complaint arrived at 11:45. The problem started at 10:15. History shows the gap.
Before touching the console, get three facts: who is affected (one user, one department, everyone), what is slow (login, one application, file opening), and since when. One user since yesterday is a workstation problem until proven otherwise. Everyone since 11:40 is a server event with a start time - and a start time is gold, because it is where you begin in the history graph.
Disks cause more "slow server" cases than everything else together:
If the disk graph changed at the complaint's start time, you are probably done investigating.
Memory next: look for the staircase pattern - usage climbing in steps and never coming down. That is a leaking process, and the fix order is restart that service (temporary), then patch or replace the application (permanent). Watch paging too: heavy paging means the server is living on disk, and everything feels ten times slower.
CPU last, because it is the most misread graph. Short spikes are normal. Sustained 90%+ matters - and even then, find which process before concluding anything. A single stuck report or update job is not a reason to buy a bigger server.
If disk, memory and CPU all match their normal patterns, the slowness lives inside the application: a slow database query, a locked record everyone is queueing behind, or one client machine flooding requests. This is where application-level monitors earn their keep - database response time and slow-query views show what server graphs cannot. Going in the other order - reinstalling the application while the disk is dying - is how a one-hour fix becomes a lost weekend.
Every investigation should end with one habit: note the server's normal values (typical CPU, memory level, response time at peak hour). Without a baseline, every future graph is a mystery. With one, "is this abnormal?" becomes a ten-second answer. Most monitoring tools also offer anomaly or baseline features that learn this automatically - use them, but your own written note from a healthy week is still the fastest reference you own.
See the full live demo - adding servers, reading the dashboard and setting alerts, step by step.
▶️ Watch Full VideoA fixed-time pattern almost always means a scheduled job: backup, antivirus scan, report generation or updates. Compare the slow window with task schedules before suspecting hardware.
The symptom is solved; the cause is not. Check the history for the days before the restart - a memory staircase or filling disk will simply climb again. Restart buys time, not a cure.
Both can be. Short CPU spikes during real work are normal. Judge by response time and user experience over the polling window, not by a single peak on a graph.