cPanel sends notifications: the account is nearly full, a login came from somewhere unusual, a certificate did not renew. They are useful, and they depend entirely on one field being right.
The address must not be on this account
In cPanel, Contact Information under Preferences.
If the contact address is a mailbox on the same hosting account, the notification system fails in exactly the situation it exists for.
A full account cannot accept mail. So the warning that the account is nearly full is refused by the account it was warning. It arrives reliably while nothing is wrong and fails the moment it matters.
Use an address somewhere else entirely: a different provider, not a forwarder that still routes through this server. It takes thirty seconds and it is the difference between fixing a problem early and hearing about it from a visitor.
A second address can be added, and it is worth having when more than one person looks after the site.
Which notifications to keep
Disk quota approaching. The most valuable one. A full account breaks email, uploads, database writes and sessions simultaneously, and none of the resulting errors mentions disk. There is more on what that looks like from the front in monitoring your hosting resources.
Suspicious login notices. Low volume, high value. A login from a country you have never visited is worth an interruption.
Certificate renewal failures. Renewal is automatic and silent, which means a failure is also silent until the certificate expires and every visitor sees a warning.
Account suspension notices. Self-evidently worth receiving.
Which to turn off
The routine successes. Confirmation that a backup completed, that a certificate renewed, that a cron job ran.
This is not about tidiness. A mailbox receiving a dozen "nothing happened" messages a day is one nobody reads, and the notification that mattered arrives into a folder that is already ignored. Turning off the noise is what makes the signal work.
The exception is a job whose failure would otherwise be invisible, but the right handling there is to alert on failure rather than to confirm success. Setting up cron jobs deals with arranging that.
The password change notice
Keep it, always.
A password change you did not make is the clearest possible signal that something is wrong, and it is one of the few notifications that gives you time to act before damage is done.
Check it actually arrives
A contact address that was set correctly two years ago may now be an employee who left, or a domain that expired.
The test is trivial: change something small that triggers a notification, and confirm it lands. Do it once, and again whenever the people involved change.
Also check the receiving mailbox's spam folder the first time. Automated mail from a server is exactly the shape of message that gets filed there quietly, which produces the same outcome as having no notifications at all.
On a reseller account
The contact address decides who hears about a customer's account. The customer, or you.
Both is usually right for disk warnings, and the reseller alone for anything the customer cannot act on. What is worth avoiding is the arrangement where nobody is listening because each assumed the other was.
The reseller support workflow goes into deciding that deliberately rather than by default.
Where the thresholds are set
The disk warning is the most valuable notification and its usefulness depends entirely on when it fires.
A warning at 90% of a quota that fills over months is ample notice. The same warning on an account that fills in a day is delivered while everything is already breaking.
cPanel exposes warning and critical percentages, and on a fast-growing account the first should be considerably lower than the default, 75% rather than 90% buys days rather than hours.
The same applies to bandwidth, where the useful warning is one that arrives with enough of the month left to do something about it. Monitoring your hosting resources sets out what actually runs out first.
Notifications the server sends to itself
Beyond the account's contact address, the server has its own, and on a reseller account the two are frequently confused.
Account-level notices go to the address in Contact Information. Server-level notices; a service down, a disk approaching capacity on the machine, an update applied, go to the address configured in WHM and reach the reseller or the administrator instead of the customer.
Both matter and they answer different questions. A customer who receives server-level alerts they cannot act on will start ignoring all of them, which is how the one that mattered is missed. There is more on routing them deliberately in the reseller support workflow.
Contact details are also a recovery route
The address on the account is what a password reset uses. That has two consequences worth thinking about.
It must be an address you can still reach if the hosting account is unavailable, which is the same argument as the disk warning, for a different reason.
And it is a target: anyone who can change that address can reset the account's password. Which is why a change to it should itself produce a notification, and why the field deserves the same care as a password.
Check it whenever staff change, and treat an unexpected notification about a contact change as an incident instead of an oddity. Securing your hosting account picks it up from there.
When the notifications stop arriving
Silence is ambiguous: either nothing has happened, or the delivery has broken.
The usual causes are an address that no longer exists, a filter that files them away, or the receiving provider rejecting automated mail from the server.
grep -i 'cpanel' /var/log/exim_mainlog | tail -20
That shows what the server tried to send and what happened to it. A rejection there explains months of apparent quiet, and it is worth checking once instead of assuming the absence of alerts means the absence of problems.