The hub itself
This is what you actually look at.
Every picture below is the real hub, photographed by a script from the templates that ship — against a fleet of six invented sites, so nothing here is anybody's data and nothing goes stale the moment a version number moves.
The sites are deliberately in different states. One is clean, one is down, one has malware, a modified core file, two known vulnerabilities and a line in its .htaccess that runs code on every request. A gallery of six healthy sites would show you nothing at all.
The fleet
What you open in the morning: everything that is wrong, across every site, before you have opened any of them.
Overview
The landing page. Every problem across the fleet, what is covered, and what was done this week — before anybody opens a site.
Every site
The fleet, with an uptime state, pending updates, a security score and a badge per site — and a tick box on each, so one action covers forty.
The work queue
One queue, worst first. Every open issue across every site, each row linking to the section that fixes it.
One site
Thirteen sections, each a real page with its own URL, grouped under Security, Maintenance and Public site. Every badge is a count of something waiting inside.
A site at a glance
One site's overview: the six vitals, and a *Needs attention* list that names each current problem in a sentence.
Security, itemised
The security score, spelled out. Every point missing names the thing that took it — and what was never measured is listed separately, because "we could not look" is not "all clear".
Updates and inventory
The inventory: every plugin and theme, what is pending, which pending update closes a real CVE, and the must-use plugins nothing else lists.
Site health, in depth
WordPress' own Site Health tests, beside the deep health checks that run hourly as drift detection — the same five that verify every update.
Uptime
Uptime and response time, with each outage's length — and, where a remote vantage point disagreed with us, which of the two was right.
Performance
Core Web Vitals measured in a real browser, the heaviest resources, and the files the page asked for and did not get.
Broken links
Dead links, with the pages to edit — and the ones that could not be verified kept separate, because a report whose first rows are wrong is a report nobody opens twice.
DNS and mail authentication
DNS records kept as history, and the SPF / DKIM / DMARC grade with the exact record to publish for each problem.
What leaves the hub
Alerts, reports and the documentation — the parts your client sees, in your name rather than ours.
Alerts
Who hears what. Every category with its own opt-in, and destinations beyond email — Telegram, Slack, Discord or your own webhook.
Reports
Three reports: the working list you read, and the two branded ones you hand a client.
Monthly customer reports
Last month's report, emailed to each customer as a PDF in your branding, on the same day every month, without anybody remembering.
The help centre
Thirty articles served from the hub itself, so "open the backup settings" is a link rather than an instruction.
See it against your own sites
Install the plugin, paste one connect string, and the first page fills in within seconds — every check runs the moment a site is connected rather than over the following week.