• Locked out of my own site. Use the Unblock IP screen from another network, or delete the guardforge_lockout_* transients. If 2FA is the blocker, a recovery code works once.
• Nothing gets blocked and no alert e-mail arrives. Check GuardForge > Settings for the staging-mode panel. If it says the mode is on, the site looks like a copy — the login log will show soft_locked rows where a lockout would have been. The panel names the signal that decided it, and “always treat this site as production” turns it off.
• A file is reported as “not in the official build”. That is the finding worth acting on: nothing wordpress.org published contains it. Open it before deleting it, and use the Restore button only on core files — for a plugin, reinstall the release from the Plugins screen.
• Everything is “no reference”. That is normal for themes and for premium or custom plugins: nobody publishes hashes for them, so they stay on the scan-to-scan comparison. It is also what a fresh install shows for a day or two after a release, while wordpress.org catches up; the answer is cached for three days in that case, not thirty.
• “Verify chain” says the chain is broken. It names the first row that failed. Check whether anybody has edited or deleted rows in the table directly — restoring a database backup over a live log will also break it, because the rows after the restore point at hashes the restored tail no longer produces.
• “Verify chain” says the check was truncated. The log is larger than fifty thousand rows. The check covered the oldest part; there is no resume today. Lower audit_log_keep_days if the table is routinely that large.
• The vulnerability list is empty, or says the feed brought nothing. That is honest, not broken: the plugin refuses an empty document rather than clearing the mirror on the strength of somebody else’s bad deploy. It will retry on the next daily run.
• The vulnerability screen shows a dash in the Summary column. Free rows have no summary — the public endpoint does not send one. Pro rows do.
• Patch by update never does anything. It needs all of: the switch on, an advisory that names a fixed version, an update WordPress is actually offering, and that offered version outside the advisory’s affected range. A range it cannot parse, a * range, a staging copy, a symlinked plugin directory, a deny-list entry, or a failure in the last 24 hours all stop it — by design.
• An alert never arrived. Press “Send test” on the channel: it uses the same dispatcher and reports the HTTP status. Then check the channel’s minimum severity, the digest mode (an hourly or daily digest is not late, it is batched) and quiet hours — which hold everything except lockdown and malware.
• The site locked itself down. Auto-lockdown fired: twenty addresses locked out inside ten minutes, or a malware finding if that trigger is on. The audit log has both the reason and the timestamp; it lifts itself after the configured window, or you can lift it by hand from GuardForge > Lockdown.
• The badge link 404s. It is refused when the site’s host name no longer matches the one the badge was issued for — which is what stops a staging copy publishing the live site’s grade. Re-issue it from GuardForge > Hardening score.
• A plugin stopped working after activation. The REST allow-list is the usual cause. Add the plugin’s namespace under GuardForge > Settings > API & protocols.
• The WAF blocked a legitimate request. The block is logged with the rule that fired. Administrators are exempt; add the parameter to the exceptions if the rule is too broad for your content.
• Cloudflare sync says “not connected”. Both the Zone ID and a token are required, and the token needs Firewall Services → Edit on that zone.
• Everyone shows up as a Cloudflare address in the login log. The edge range list is stale. With Pro it refreshes daily; the Cloudflare screen says when it last changed.