Most WordPress outages are not attacks. Four causes account for the overwhelming majority: a plugin or theme update that throws a PHP fatal error, a PHP resource limit set below what the installed plugin set needs, a database that stops answering because MySQL hit a limit or the disk filled, and a wp-config or site URL value edited to something the server cannot serve from. Each has a different recovery path, and the fastest one is almost never wp-admin, because wp-admin is usually down with the rest of the site. Rank them by mean recovery time instead of frequency and the ordering inverts: the most common failure is the cheapest to undo, while the rarest, InnoDB corruption on a full disk, is the one that ends in a restore from backup.
TL;DR by reader profile:
Family running one shared site (Marta hosts the household blog, a shared photo gallery and a recipe page on a small VPS): put DISALLOW_FILE_EDIT and automatic plugin updates under manual control, and keep WP-CLI installed, because the single most likely outage is a well meaning family member updating a plugin from a phone and having no way back in.
Volunteer admin for a community group (Ade maintains the sports club site nobody else touches): budget for a documented restore drill twice a year rather than more monitoring, because your real risk is not detection speed, it is discovering the backup was never tested.
