All about health checks
Health checks look for things that hurt the performance, security or reliability of your sites and applications. They cover both layers: the servers Cyberfusion runs for you, and the applications you run 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.
The page opens on the first tab that has open issues, so you land on something actionable instead of an empty list. Every open issue has a wrench button that takes you straight to the page where you fix it.
If the cluster has never run its checks, the page says so and asks you to click 'Refresh'.
The three tabs
- 'Hosting security' — the server and platform layer: database encryption on disk, SSH exposure, automatic OS security updates.
- 'Application security' — the software you run: outdated PHP versions, 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 number next to each tab name is its count of open issues.
Severities
Shown as a badge in the 'Status' column:
- 'warning' — leaves a known security hole open. Outdated PHP and CMS versions get this, because versions past their security support no longer receive fixes for vulnerabilities that are public knowledge.
- 'recommendation' — worth improving, but not an open hole by itself. Most performance checks and the hosting security checks.
A check that passes shows 'OK'.
Reading the table
- 'Status' — 'OK', or the severity. 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. Full text in the tooltip.
- 'Since' — how long the check has been in its current state. It 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.
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 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 reads 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. |
How often checks run
Every 24 hours. Click 'Refresh' to run them immediately, for example after fixing something.
A refresh queues a task collection. Not all checks are instant — some ask the cluster 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; one without any domains never gets the QUIC check.
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.
- One issue — click the bell button on its row.
- Several at once — tick the rows and use 'Silence' in the bar at the bottom.
Only open issues can be silenced; a check that 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 open before the run. Any new issue triggers a notification: 'Health check found 1 new issue', or 'Health check found 3 new issues'. It 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 have not fixed yet does not message you every day. Silenced issues never notify.