WHM shows you the state of the services your accounts depend on. The web server, the mail system, the database, DNS. On a reseller account you can look at all of it and restart almost none of it, and knowing which is which saves time when something is wrong.
What the status view tells you
Service Status lists each service with whether it is running and its resource usage. A stopped service explains an outage immediately, and that is the point of looking.
The distinction that matters: a stopped service affects every account on the server, including other resellers' clients. Your own account cannot cause it and your own account cannot fix it.
So the useful question when checking this screen is not "how do I restart it" but "is this a server problem or mine".
One account or several
This is the fastest diagnostic available to a reseller, and it takes ten seconds.
If one client reports a problem, check another of your accounts. If the others are fine, the fault is in that account; its quota, its configuration, its application.
If several unrelated accounts fail at the same moment, it is server-side. Stop diagnosing individual accounts and open a ticket, because working through them one at a time is time spent on something you cannot fix.
Server load
WHM shows load averages, which represent how many processes are waiting to run. High load means the machine is busier than it can keep up with.
On a shared server that is frequently nothing to do with you: another account's traffic, a backup running, someone else's runaway process. Your accounts feel it either way, which is the nature of the tier.
What is worth checking is whether one of your accounts is contributing. A client site with no caching under a traffic spike consumes real processing, and that is something you can act on.
Mail queue
Worth looking at periodically even when nothing is wrong.
A queue that is growing means mail is not being delivered, and a queue that is suddenly enormous usually means one account is sending in volume, which on a shared server is almost always a compromised site rather than a client's newsletter.
That situation escalates quickly: the server's address gets blocklisted, and then every account on it has mail delivery problems. Noticing early is the difference between suspending one account and explaining to all of your clients why their mail bounces.
What you can restart
Very little, deliberately. Restarting a shared service interrupts every account on the server, so it is a root operation.
What you can do at account level is enough for most situations: suspend an account that is causing a problem, adjust its limits, or open its cPanel to look at what it is running.
When to open a ticket rather than investigate
Four situations, and recognising them saves hours.
Several unrelated accounts failing at once. A service showing as stopped. Load that is high with none of your accounts responsible. Mail queuing server-wide.
Include what you observed, which accounts, and when it started. A ticket saying "several of my clients report their sites are down since 14:20, other accounts on the server appear affected" is acted on immediately; "something seems wrong" is a conversation.
Tell your clients before they ask
During a server-side problem, a short message saying you are aware and looking into it prevents the queue of individual reports that would otherwise take the attention you need.
It is also the difference between a reseller who appears in control and one who appears absent, and clients remember which they dealt with. Reseller best practices goes over the wider point.
When a service is down, the reason is usually already written out in plain language somewhere. For where to look first, see Where Server Logs Live and How to Read Them.
Distinguish your server from the network
A reseller's first question when something is unreachable is whether the problem is inside the account, on the server, or between the visitor and the machine, and the three have different owners.
curl -sI -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/
mtr -r -c 20 example.com | tail -5
A response with a good status means the server is serving and the report is about something narrower. No response with clean routing points at the server; packet loss partway points at the network, which is the host's problem rather than yours.
Establishing that before opening a ticket changes what you write and how quickly it is resolved, and it stops the exchange where two parties each believe the other is at fault.
Check whether it is one account or the machine
The single most useful discrimination, and it takes one command.
uptime ps aux --sort=-%cpu | head -8 ls /var/cpanel/users | wc -l
If load is high and one account's processes dominate the list, that account is the cause and the other customers are victims. If load is high with no dominant account, the machine is oversubscribed or something server-wide is wrong.
The first is a conversation with one customer; the second is a conversation with your host. Reporting the second as though it were the first wastes everybody's time. There is more on the first case in handling a client who outgrows shared hosting.
What the status view does not show
Services can report as running while not working, and the view reflects the process instead of the behaviour.
A mail server accepting connections and refusing every message shows as up. A database running with a full disk shows as up. A web server serving errors shows as up.
curl -sI https://example.com/ | head -1 mysql -e 'SELECT 1' 2>&1 | head -2 exim -bp | wc -l
Testing what the service does, rather than whether it exists, is what catches those, which is also the difference between monitoring that alerts usefully and monitoring that reports green during an outage.
Keep a note of what normal looks like
Every figure on the status view is only meaningful against a baseline, and resellers rarely have one because they look at it during problems.
Record the load, the mail queue length and the disk usage during a quiet hour and during a busy one, once. Two readings are enough to know whether today's numbers are unusual.
Without that, a load figure produces either unnecessary alarm or false reassurance, and there is no way to tell which. Understanding load average goes over reading it against the core count.