All about health checks
Health checks look for things that hurt the performance, security or reliability of the sites and applications on a cluster. They cover both layers: the servers Cyberfusion runs for you, and the applications running on top of them. An outdated PHP version, SSH open to the whole internet, a WordPress install missing its database indexes, a WooCommerce shop storing orders the slow way.
Wondering what gets checked, how often, and what to do with an issue you don't want to fix? This article lists every check, explains the categories and severities, and covers silencing and notifications.
Where to find health checks
Open a cluster, then click 'Health Checks' under 'Health' in the sidebar.
If the cluster has never run its checks, the page says so and asks you to click 'Refresh'. Otherwise you see the checks split across three tabs, with the number of open issues next to each tab name.
How often checks run
Checks run automatically every 24 hours. Click 'Refresh' to run them immediately, for example after you've fixed something and want the list to catch up.
A refresh queues a task collection. The checks are not all instant: some of them ask the cluster itself for information, such as the InnoDB report or the WordPress state of every site, so give it a moment before the page reflects the new state.
Only checks that apply to a cluster run on it. A cluster without MariaDB never gets the InnoDB or database checks, and a cluster without domain routers never gets the QUIC check.
Categories
Every check belongs to one of three categories, which are the three tabs on the page:
- 'Hosting security': the server and platform layer. Whether the databases are encrypted on disk, whether SSH is open to the whole internet, whether the operating system installs its own security updates.
- 'Application security': the software you run on top. Outdated PHP versions and outdated CMS versions.
- 'Performance': settings that make sites slower than they need to be. Database memory, table defragmentation, QUIC, missing WordPress indexes, WooCommerce order storage.
The page opens on the first tab that has open issues, so you land on something actionable instead of an empty list.
Severities
Each issue carries a severity, shown as a badge in the 'Status' column:
- 'warning': something that leaves a known security hole open. Outdated PHP versions and outdated CMS versions get this severity, because versions past their security support no longer receive fixes for vulnerabilities that are public knowledge.
- 'recommendation': something you should improve, but that isn't an open hole by itself. Most performance checks and the hosting security checks get this severity.
A check that passes shows 'OK' instead of a severity.
What each check looks at
Hosting security
| Check | What it looks at |
|---|---|
| Database encryption at rest enabled | Whether the databases on the cluster are encrypted on disk. Without it, anyone with access to the server's filesystem can read the database files directly. |
| SSH restricted to specific IP networks | Whether the SSH firewall rule allows the whole internet. Restricting SSH to the networks you actually connect from removes the constant background noise of brute-force attempts. |
| Automatic OS upgrades enabled | Whether the operating system installs its own security updates. Without this, a fix only lands when someone schedules an upgrade by hand. |
Application security
| Check | What it looks at |
|---|---|
| FPM pool PHP version up to date | Whether an FPM pool runs a PHP version that is past its security support. |
| UNIX user PHP version up to date | Whether a UNIX user's default PHP version is past its security support. |
| CMS version up to date | Whether a CMS runs a version with known security vulnerabilities. See CMS versions. |
Performance
| Check | What it looks at |
|---|---|
| InnoDB buffer pool size sufficient | Whether all active database pages fit in memory. When the data outgrows the buffer pool, the database has to read from disk instead, and queries get noticeably slower. See InnoDB buffer pool. |
| Optimising for database enabled | Whether the database is defragmented periodically. Defragmented tables take less disk space and are faster to query. |
| QUIC enabled for domain router | Whether the domain serves HTTP/3. QUIC needs fewer round trips to set up a connection, which shows up most on slow or high-latency networks such as mobile. |
| Database indexes created | Whether a WordPress site has the database indexes Cyberfusion recommends. See WordPress database indexes. |
| WooCommerce HPOS enabled | Whether a WooCommerce shop stores orders in dedicated tables. See WooCommerce HPOS. |
Reading the table
Each row shows:
- 'Status': 'OK', or the severity of the issue. Silenced issues also get a 'Silenced' badge.
- 'Check': which check this is.
- 'Object': the specific FPM pool, UNIX user, database, domain router, firewall rule or cluster the result is about. Click it to open that object.
- 'Motivation': why the check exists and what happens if you ignore it. The full text is in the tooltip.
- 'Since': how long the check has been in its current state. This resets when a check flips between healthy and unhealthy, so it tells you how long an issue has been open, not when the check first ran.
Open issues have a wrench button that takes you straight to the page where you fix it: the FPM pool for an outdated PHP version, the OS properties form for automatic upgrades, the InnoDB page for the buffer pool.
Silencing issues you don't want to fix
Not every recommendation applies to every cluster. A staging cluster may not need encryption at rest, and a site may have a reason to stay on an older PHP version for now.
Click the bell button on a row to silence that issue, or tick several rows and use the 'Silence' button in the bar at the bottom to silence them together. Only open issues can be silenced; a check that currently passes has nothing to silence.
A silenced issue:
- stays visible in the list, greyed out, with a 'Silenced' badge;
- no longer counts towards the issue count on its tab;
- no longer triggers notifications.
Click the bell button again to unsilence.
Notifications
After every run, Cyberfusion compares the open issues to the ones that were open before the run. If any issue is new, you get a notification: 'Health check found 1 new issue', or 'Health check found 3 new issues' when there are more. The notification lists each new issue with its motivation, and links back to the health checks page.
Issues that were already open do not notify again, so a problem you haven't fixed yet doesn't send you a message every day. Silenced issues never notify.