cPanel can serve calendars and contacts alongside email, using the same account credentials. It is a genuinely useful feature that almost nobody switches on, largely because it is filed under a name people do not recognise.
What it actually provides
Two open protocols that phones and desktop clients already speak.
CalDAV for calendars, appointments sync between devices, and calendars can be shared with colleagues.
CardDAV for contacts. One address book, updated on a phone and present on a laptop.
Both use the mailbox's own address and password, so there is no separate account to create or manage.
Turning it on
In cPanel, open Calendars and Contacts. Choose the mailbox, and the screen shows the connection details plus, on most systems, a configuration file you can send to the device.
On a phone, adding the account is usually a matter of choosing the CalDAV or CardDAV option, entering the full email address as the username, and giving the server name.
The username is the full address, not the part before the @. The same trap as configuring mail, and the same symptom of an authentication failure that looks like a wrong password. How to Configure Email on iPhone and iPad walks through the mail settings alongside it.
Where it fits, and where it does not
It suits a small team that already has mailboxes here and wants shared calendars without another subscription.
It does not replace a full collaboration suite. There is no meeting-room booking, no availability lookup across an organisation, and the sharing model is simpler than people used to a corporate calendar expect.
If your requirement is scheduling across dozens of people, a hosted suite is the right answer, and if it is three people who want to see each other's appointments, this does that today at no extra cost. How to Use an External Mail Provider with Your Domain walks through the alternative.
It counts against your disk
Calendars and contacts are stored in the account like mail, so they consume the same quota.
Normally that is trivial. What is not trivial is a calendar with attachments, or a contact list with photographs for hundreds of entries, those grow in a way people do not anticipate because they think of them as text.
If an account is near its limit, this is one more thing on the list to check. Managing Mailbox Quotas and Email Disk Usage sets out what usually fills one.
Backups: check what is included
The item worth verifying before relying on it.
A full account backup normally includes this data because it lives in the mailbox structure. A backup configured to exclude mail may exclude calendars and contacts with it, and the loss is not noticed until somebody needs an old appointment.
Restore a test account once and confirm the calendar came back, instead of assuming it did. How to Restore a cPanel Account from Backup in WHM sets out doing a partial restore.
Sharing has limits worth knowing
Calendars can be shared with other mailboxes on the same account, and the permissions are coarse compared with a dedicated platform.
Decide who owns each shared calendar. A calendar belonging to a person who leaves is a calendar that disappears with their mailbox, and moving it afterwards is more awkward than creating it under a role address in the first place. How to Set Up Shared and Role-Based Mailboxes goes over that pattern.
Use the encrypted ports
Connections carry your mailbox password and your appointments, so use the secure connection settings the screen provides instead of the plain ones.
On some clients the difference is a single checkbox that defaults to off, and a connection that works either way gives you no signal about which you got: check the setting in place of the outcome.
Test on a second device
The point of this feature is synchronisation, and a single device proves nothing.
Add an appointment on the phone, confirm it appears on the laptop, then edit it on the laptop and confirm the change reaches the phone. Do the same with a contact.
That five-minute check is what distinguishes a working setup from one where each device is quietly keeping its own copy, which is the failure people discover months later, having lost the entries made on the device that broke.
Check what is actually being synchronised
The service holds several kinds of data and clients frequently connect to only some of them.
curl -sI https://example.com:2080/ 2>/dev/null | head -1 dig autodiscover.example.com CNAME +short dig _caldavs._tcp.example.com SRV +short
A client configured for mail alone will not show calendars, and the setup screens rarely make that obvious.
The discovery records are what allow a client to configure itself. Where they are absent, everything has to be entered by hand, and that is the usual reason one person's devices work and another's do not.
Sharing behaves differently between clients
The standards involved are implemented unevenly, and a calendar shared successfully in one application appears read only or not at all in another.
Test with the specific applications the people involved actually use rather than with one. A shared calendar that works between two of the same client and fails with a third is normal rather than a fault.
curl -s -u user:pass https://example.com:2080/calendars/ 2>/dev/null | head -5
Where the arrangement has to work across several kinds of device, confirm it before telling anybody it is available. The alternative is discovering the limitation after people have started relying on it.
It counts against the same disk as everything else
Calendar and contact data is small individually and accumulates, particularly with attachments and long histories.
du -sh ~/.caldav ~/.carddav 2>/dev/null du -sh ~ 2>/dev/null | tail -1 quota -s 2>/dev/null
An account near its limit for other reasons will stop synchronising, and the failure appears on people's devices as a sync error rather than as a disk message.
Confirm the data is included in whatever backup arrangement covers the account. It frequently is not, and a calendar rebuilt from memory is a poor substitute for the original.