Fleet Sentinel

Fleet dashboard

• Sites at risk, critical CVEs, pending updates, sites down and silent agents.
• Uptime and severity trend charts, and a prioritized “needs attention” list.

Site directory & detail

• Search, status filter, pagination, bulk actions, mute alerts, sync now, and add/delete with pairing keys.
• Twelve tabs per site, from plugins and findings to email tests, activity and backups.
• Notes and an audit trail of who changed which plugin.

Vulnerabilities

• Ingests the Wordfence Intelligence v3 feed (free or Pro key), streaming a catalog of over 117 MB.
• Matches it against every installed plugin and theme, and resolves or reopens findings as versions change.
• A rate-limit gate, error diagnosis, and key testing with auto-save.

Updates & findings

• Pending plugin/theme updates grouped across the fleet, labelled correctly.
• Automatic findings: vulnerabilities, updates, core updates, PHP end-of-life, TLS expiry, site down, agent lost.
• TLS expiry is read from the socket: a warning at 21 days and a critical finding at 7.
• Any finding can be assigned to a team member who can see the site.

Uptime monitoring

• A built-in prober that starts with a HEAD request and escalates to a browser-style GET.
• It recognises a WordPress failure page served with a 200, which a status-code check would pass.
• Two failed sweeps open an incident. Incidents carry durations, and uptime is rolled up per day for 30 days.
• UptimeRobot and BetterStack integrations with an inbound webhook.

Alerts in Google Chat and email

• Destinations are Google Chat spaces or email lists, with per-site or fleet-wide routing rules.
• 24 event types, a minimum severity per rule, quiet hours, per-site mute and a delivery log.
• Daily and weekly summaries at 8 AM in each destination's time zone.
• Email goes out through Resend or any SMTP server, set up by the superuser.

Multi-tenant fleets

• Fleets are separate tenants with per-fleet membership and roles; access can be restricted to chosen sites.
• A fleet switcher that stays in sync across browser tabs.
• Hardened fleet icon upload: content-sniffed type check, no SVG, decompression-bomb protection, re-encoded to WebP up to 512×512.

Access control & settings

• Viewer, editor, admin and superuser roles, sharing 37 permissions between them.
• Sign-in is by invitation, sent by email. A matching email domain grants nothing by itself.
• Removing someone, or a change of superuser, takes effect on their next request.

Site scans

• Scan one page, or design a scan of up to 500 sitemap pages and repeat it daily or weekly.
• Eight focus areas, from SEO and accessibility to the security surface and WordPress hygiene.
• Rules and PageSpeed run first. Jev decides whether the copy needs a review, and only then does Claude read it.
• The dialog prices a scan before it runs, against each fleet's own AI keys and daily allowance.

Broken links & sitemaps

• Checks robots.txt and the sitemap, then the pages it lists and the internal links on them.
• A page that used to work and now fails is a regression and sends an alert. A link that never worked is recorded quietly.
• A failure counts only after a recheck at least ten minutes later.
• The plugin also reports the paths visitors get a 404 on, and the panel rechecks them itself.

Email delivery tests

• Sends one fixed message through the site's own wp_mail() to a single-use address.
• Checks SPF, DKIM, DMARC alignment, reverse DNS, three blocklists and an rspamd spam score.
• Gives a verdict, a score out of 100 and fixes to copy. Two failures in a row send an alert.

Activity log

• Sign-ins, users and roles, plugins, themes, settings, content and WooCommerce order statuses.
• Each event says who, how the request came in and which plugin or theme's code made the change.
• Search, filters, CSV or JSON export, and alerts for new administrators, installs and brute-force bursts.
• IP addresses are anonymised unless the fleet chooses otherwise.

Encrypted backups

• Opt-in: a site administrator enrols the site in wp-admin and compares the fleet key's fingerprint.
• The site encrypts each backup with libsodium before it leaves, so a destination holds data it cannot read.
• Copies go to panel storage, S3-compatible storage, SFTP, FTP/FTPS or Google Drive.
• A stepped job built for shared hosting resumes after PHP is killed mid-run.

Self-diagnosis

• Every hour, 11 platform checks and 15 fleet checks: late jobs, failing alert destinations, broken keys, backups and mail.
• Each problem says what it means and what to do, with AI explanations when the fleet has keys.
• Safe fixes, such as re-running a job, are offered only when the problem lists them, and are audited.

Transport

• The panel tries several transports in turn (a signed RPC endpoint, then admin-ajax, then REST variants) and remembers which one works.
• Every request is signed with HMAC-SHA256, with clock-skew correction and jittered retries.
• admin-ajax is always among the transports tried, so a site left in maintenance mode can still be reached.

Failure detection

• Failures are sorted into 15 types (blocked, timeout, TLS, clock skew, a different panel and more).
• A φ accrual failure detector (Hayashibara et al.) decides when an agent is unreachable, never sooner than 4 minutes and never later than 20.
• If most sites fail at once, the panel assumes its own network is the problem and holds alerts.

Request authenticity

• Requests between panel and agent are signed over the method, path, timestamp, nonce and body hash, carried in five headers.
• A 300-second clock window, single-use nonces, a timing-safe comparison and rate limits.

Secrets

• Site secrets, Chat webhook URLs and each fleet's AI keys are encrypted with AES-256-GCM on the panel.
• The agent encrypts its own secret with a key derived from the site's AUTH_KEY.
• Backup downloads and the recovery-key export need a sign-in within the last 15 minutes.

Sign-in and sessions

• Google sign-in only, with a verified email. The account and its fleets are read again on every request.
• The middleware denies by default, and every page carries a Content-Security-Policy.

Tenancy & roles

• Every tenant query is scoped to its fleet, and audit logs are scoped per fleet.
• A site in another fleet returns the same 404 as a site that does not exist.
• Platform-wide actions and log deletion are superuser-only, so fleet admins can't erase the audit trail.

Sample data

• 3 fleets and 43 sites on .example domains.
• 621 plugins and themes, 43 findings (26 open) and 12 incidents.
• Vulnerability ids are invented and prefixed DEMO-CVE.

Switched off

• Sign-in: the demo opens as a superuser.
• Webhook URLs are discarded, and API keys are kept only as a mask.
• Scans, crawls, email tests, backups and background jobs are simulated. The demo has no plugin download.

Automated

• 2,832 passing Vitest tests in 212 files (run on 28 October 2026), plus 17 end-to-end tests that run only when asked.
• Cross-language end-to-end tests run the real PHP plugin against the TypeScript panel.
• 21 PHP test scripts, including a backup job killed 50 times that must resume each time.

Reviews

• Three reviews wrote 315 edge-case tests. Each failing one proved a bug, and all 52 are fixed.
• Every page checked at 375, 768 and 1440 px: no sideways scroll on a phone, and no touch target under 24 px.
• An earlier pass tested every page as each role and found 8 bugs, including 3 security issues.

Not built

• It reports pending updates and cannot apply them.
• No client-facing or white-label reports.
• Backups can be verified and downloaded, but there is no one-click restore to the site.
• No two-factor sign-in of its own.

Operational

• Accessibility checks and phone screenshots need a separate browser service. Without it, those two scan areas are skipped.
• Email tests need a receiving subdomain on Cloudflare Email Routing.
• On Vercel's Hobby plan cron fires once a day, so minute-by-minute checks need the checker worker or the Docker scheduler.

Vercel

• Monorepo deployed with a root vercel.json, cron configuration and maxDuration limits for the Hobby plan.
• Environment separation and secrets kept out of git; Google OAuth redirects configured.
• The public demo is the same build with demo mode on, served at fleetsentinel.hamzaahmadaslam.com.

Docker

• One image runs as the web server, the worker, the cron scheduler and the migration runner.
• The scan renderer, its egress proxy, rspamd and unbound run as separate containers. The renderer and rspamd have no route out.

Data & plugin

• Neon Postgres migrations applied in production through a migration script.
• The plugin zip is built from source on every deploy and offered in the panel. A build fails if its version numbers disagree.

Cost

• A pause switch takes the panel offline so an idle Neon database can sleep.
• Removed a scheduled GitHub Actions workflow that failed every run and would have burned billed minutes.