Visitors see the interface, but a project's resilience is decided by what sits underneath it: server configuration, updates, backups, logs, and monitoring.
A system, not a pile of settings
Good infrastructure should be reproducible and easy to understand. The project owner should know where the data lives, how fast the service can be restored, and who gets notified when something breaks.
Backups you can actually trust
A backup that's never once been restored in a test environment is an assumption, not a guarantee. Three things matter: regularity (backups should run on a schedule, not "whenever someone remembers"), storing them separately from the server itself (otherwise one incident wipes out both the data and its copies), and testing the restore -- at least once every few months, actually restore a backup and confirm the site comes back up.
Monitoring and alerts
Monitoring isn't there for pretty graphs -- it's there so a problem is caught before your users notice it. A minimal set: site uptime, disk space, server load, and SSL certificate expiry. An alert needs to reach a specific person, not get lost in a general log nobody reads.
Updates without the risk
Updating the CMS core, modules, and system packages matters for security, but it's itself a source of risk if done without a backup and without testing on a staging copy of the site. A sensible order: take a backup, update, check the key scenarios (homepage, contact form, admin panel), and only then consider the update done.