From a nightly check to evidence your client can inspect.

Forty client websites produce steady, low-grade noise: a certificate expiring somewhere, a plugin two versions behind, a Lighthouse score that slipped after a landing page went live, a tracking script somebody added without asking.

Provision a Linux, Plesk or Synology host with the same pinned install command, let its agent turn heartbeat, mail, backup, disk, container health and WordPress health into owned work, and see within six hours when its address lands on a mail blacklist. Agent updates are signed and verified on the host. One host check reports subscription, storage and WordPress state together, including websites reached under an alias or addon domain on their selected host. Every check states its reason, the Docker check lists container health, load and restarts per container, and a check that is expected but stops being reported says so instead of looking healthy: a server that needs attention is one line on the dashboard, its full check list one click away in a side panel, and the same list sits on the hosting record it belongs to. Dashboard and Settings share the same wide server view, with per-check re-check actions for authorized users and separate History and Configuration tabs. Failed WP Toolkit plugin updates surface by affected site as a warning and one current task assigned to the server owner, then clear after a successful retry. Known plugin, theme and WordPress core vulnerabilities reported by WP Toolkit open a CVE task for the website they sit on and appear in its security findings with the release that closes them, and an installation flagged as infected opens a high-priority task for the server owner. Every WordPress installation the agent finds gets a website record and appears as awaiting review until somebody says whose it is, so an installation nobody had created by hand is watched from its first check-in. If it turns out to belong to a website that already exists, it is moved there from the website itself, and the placeholder the agent created is kept and marked reviewed. A System re-check samples package updates immediately, so a report reflects updates installed moments earlier. The WordPress card and its installation table read the advisory state as it is now, so a finding somebody resolved or muted and an installation moved to another website change the numbers at once, and each row opens the findings behind it on that website's vulnerabilities page. Every check on a server also states what its coverage is, so an assessment that is overdue, still pending confirmation or never recorded says so instead of reading as a clean result. Read report reasons at a glance and export CSV or PDF evidence for audits, with daily results retained for three years and archiving that preserves the records.

Genedar runs the checks on a schedule, keeps the results as history, turns findings into work with an owner and hands the client the same evidence you are reading. Customer PDFs separate confirmed vulnerabilities, hardening, unconfirmed findings and customer responsibilities with reasons, explain check coverage, and include a one-time note when the classification changes. The website Overview puts the most urgent check and its next task action first, with links to the underlying evidence. Hosting follows with responsibilities, assignment and subscription storage labelled as shared across the whole subscription, including a clear explanation when the subscription is not linked or no measurement has arrived. Metadata editing stays in Settings. Security findings retain their identity and first seen date across scans, and the website record shows one merged security view across scanner, WP Toolkit and dependency evidence, with the recorded reason next to every finding that left the list. Findings are never deleted from the record: a wrong detection, or an area the customer owns, is suppressed with Mute, and the scope of that decision is recorded in the audit log. Every active mute is listed on the website itself with who set it, when and why, and can be undone there, and a plugin reported under several advisories is muted in one step rather than once per advisory. Every check your plan includes runs from the moment a website is in the inventory, and each module reports its own state: active, not applicable where the check cannot apply (Email DNS for a domain whose mail is hosted elsewhere, WordPress for a site that is not WordPress, the public content checks for a record marked as an application or an API), or not configured while something it needs is still missing (a GA4 property id, or a WordPress installation that is neither monitored by the server agent nor connected over the REST API). Where both exist, the server agent's inventory is the one you see, and a REST refresh never overwrites it. A check that does not apply says so instead of counting as a gap, and a module that is in the plan and applies to the site but is not configured yet appears as its own setup destination at the end of the website's tab bar, with the reason it is not running yet. Each module carries its own configuration next to its results, the record's own details sit in a small Settings tab, and a task raised from a check links to the page that lists the findings behind it. Maintenance work is a task with an owner rather than a monthly status somebody ticks, and a check that has not run says so instead of counting as done.