Performance
Mobile and desktop Lighthouse scores kept as history, so regressions become visible changes.
Website Operations
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. 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 disappears with it. A System re-check samples package updates immediately, so a report reflects updates installed moments earlier. 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. 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), 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). A check that does not apply says so instead of counting as a gap, and a module that is not configured is offered for setup on the website overview rather than hiding behind an empty tab.
Ten modules, grouped by the outcome they defend
Availability
Uptime, response time, incidents, SSL context and the links that quietly broke.
Security & compliance
Headers, exposed paths, SPF/DKIM/DMARC, DNS blacklist reputation of the mail servers, and the third-party domains a visitor loads.
Dependencies
WordPress plugin state alongside npm, Bun and NuGet vulnerability findings, each with the release that closes it where the advisory names one.
Analytics & search
GA4 traffic, Search Console performance and URL inspection on the website record.
A finding is the beginning of work
A finding that only exists in a dashboard is a finding nobody owns. Genedar turns it into assigned work with a due date, while the source module remains attached as evidence.
A critical CVE does this by itself: one task per website for the website responsible, due in seven days, listing the affected packages with the version that closes them, and closing itself once a later scan finds none left.
The dashboard therefore shows open work rather than counters: sites down, open CVE tasks, sites with security findings, server alerts, certificates about to expire. Every number opens the list of what it counted, with the reason next to each entry: which monitor has been down since when, the newest finding with its date, the certificate expiry, the CVEs behind a task. It deliberately leaves out websites outside the plan and websites you do not operate: upsell candidates and former customers.
Tasks can close when the source issue clears. The record remembers who owned the response and how long the risk existed.
Upsell and former-customer websites keep their scan evidence on their own record without entering the tenant-wide security alarm totals: only the websites you operate today produce alerts and tasks.
History, not screenshots
A screenshot proves a number was true once. A history proves that you have been watching. Every result stays dated on the website record, so an SLA claim is answered by reading rather than reconstructing.
Reports are branded, scheduled and written in the customer’s report language, addressed to the website’s CRM customer contact and any additional recipients. Every report links back into Customer Space instead of arriving as a dead PDF.
The public analyzer shows the first scan. A saved website adds ownership, history, scheduled modules and client evidence.
Start with the first scan.
Run a domain through the public analyzer, then see what the same site looks like once it has history, an owner and a scheduled report.