Greenskeeper

Greenskeeper includes a built-in “Disable All Auto-Updates” feature available in two places. On the Updates page, an amber warning banner appears whenever any plugins or themes have auto-updates enabled, showing the exact count and a “Disable All Auto-Updates” button. On the Settings page, the Auto-Updates card shows the current status — green if all auto-updates are disabled, amber if any are enabled — with the same disable button. Clicking either button disables auto-updates for all plugins and themes in one action and logs the change to the Site Activity Log. A green confirmation card then appears with instructions for re-enabling individual auto-updates via the WordPress Plugins admin screen. The feature works on both single site and multisite WordPress installations.

WordPress auto-updates run silently in the background, bypassing Greenskeeper’s update log and client reports. When a plugin auto-updates without going through Greenskeeper, the change is not recorded in the Update Log and will not appear in email reports sent to your clients. Disabling auto-updates ensures that every update on a site goes through Greenskeeper’s documented, deliberate workflow — giving you full control over when updates run, a complete audit trail, and accurate client reports.

In June 2026 WordPress.org introduced a mandatory up-to-24-hour hold on all new plugin and theme updates as part of its “Protect The Shire” initiative. An AI security scanner reviews code changes during this window before they are distributed to sites with automatic updates enabled. The policy was introduced in response to a rise in AI-accelerated supply chain attacks targeting open-source plugin repositories.

The one area where the delay is felt is in update discovery — a new plugin release or security patch may not appear on Greenskeeper’s Updates page for up to 24 hours after the developer publishes it, because WordPress.org holds the release in its review queue before making it available via the update API. If you need to apply a critical security patch before it appears in the update queue, you can install the updated plugin manually by downloading it directly from the developer and uploading it via SFTP or the WordPress plugin upload screen. Greenskeeper’s Update Log and Email Reports pages support manual update entries so the patch can still be documented and reported to your client even when applied outside the plugin.

Yes — from v2.3.1 onward, the Email Reports page includes a “Preview Email” button next to the Send button. Clicking it opens a full-fidelity preview of the email in a modal window, rendered exactly as it will appear to the client — including the current update note, any manual entries you have added, and all session update data. The preview reflects the live state of the form, so if you add a note and click Preview, the note appears in the preview immediately. From the preview modal you can: click “Send Email” to send without closing the modal, click “Go to Updates → ” to return to the Updates page if something needs to be retried, or click “Close & Edit” to return to the form and make changes before sending.

From v2.3, Greenskeeper checks whether the item already has a successful update record in the current session before running the update again. If it does, an amber informational notice appears explaining the item is already up to date, with a Retry button still available if you want to force a fresh check. The item is counted as successful so the batch completion state is not affected.

Greenskeeper dismisses the WordPress “update available” admin banner after a successful core update by clearing the update_core transient. It then shows its own confirmation notice — “WordPress X.X updated successfully” — which auto-dismisses after 4 seconds. This prevents the WordPress banner from persisting and confusing the admin into thinking the update needs to be retried.

No — from v2.2.1 onward, Greenskeeper is always the sender of record for its own emails by default. It applies its SMTP configuration only to emails it initiates (maintenance reports, admin notifications, test emails) and never interferes with WooCommerce, contact forms, password resets, or any other plugin’s mail. When Greenskeeper detects another SMTP plugin on the site, it shows an informational notice on the SMTP settings card naming the plugin and confirming Greenskeeper is operating independently. If you prefer to hand delivery to the detected plugin, a checkbox on the settings card lets you do that — with a clear warning that a failure in that plugin may prevent Greenskeeper reports from sending and will not appear in Greenskeeper’s email log.

Greenskeeper detects the following SMTP plugins: WP Mail SMTP, FluentSMTP, Post SMTP, Postman SMTP, Easy WP SMTP, Brevo (Sendinblue), Gravity SMTP, WP Offload SES, and Gmail SMTP. Detection covers both site-activated and network-activated installations on multisite.

Yes — from v2.1.11 onward, Greenskeeper includes a System Info page (Greenskeeper → System Info in the WordPress admin sidebar). It displays your full server environment (PHP version, extensions, server software), WordPress environment (version, URLs, memory limit, debug mode, database), active theme, and a complete list of active plugins with versions and authors. A sticky copy-and-paste panel lets you copy the full report as plain text to include in support tickets to plugin or theme developers.

Yes — from v2.1.10 onward, Greenskeeper can send an internal notification email to the performing administrator when a batch of updates completes. Three notification types are available, each independently toggleable in Greenskeeper → Settings → Email Notifications: (1) All updates succeeded (off by default — routine clean batches don’t need an email), (2) Some updates failed (on by default — partial failures need attention), (3) All updates failed (on by default — complete failures require immediate action). These notifications go only to the administrator, not to the client.

The Updates page now shows one of three distinct states after a batch completes: (A) All succeeded — green confirmation with a Send Report link; (B) Partial success — amber warning showing how many succeeded and how many failed, with options to retry the failed updates or send a report with only the successful ones; (C) All failed — red warning with a Retry All option. The Send Report link is never shown when all updates failed since there is nothing to report.

No. If a plugin update fails and you retry it in the same session and the retry succeeds, the failed row is suppressed from both the Update Log display and the email report. Only the successful outcome is shown. The failed row remains in the database for audit purposes but is hidden from the user-facing views. This applies to both individual retries and batch retries.

Yes — Greenskeeper includes a Site Activity Log that records user logins, failed login attempts, plugin changes, theme switches, user account changes, and WordPress core updates. The log is disabled by default and can be enabled in Greenskeeper → Settings → Site Activity Log.

Yes. The activity log is designed with GDPR data minimisation principles from the ground up. IP addresses are anonymised by default — the last octet of IPv4 addresses and the last 80 bits of IPv6 addresses are zeroed before storage, following the approach recommended by the European Data Protection Board. Log entries are automatically purged after a configurable retention period (default 90 days). You can export all stored activity data as CSV to respond to Subject Access Requests, and bulk-delete all entries at any time from the Site Activity page. Full IP address storage is available as an explicit opt-in for sites with a documented legitimate purpose under GDPR Article 6.

Authentication: user logins, failed login attempts, logouts, password reset requests, password changes. User management: account creation and deletion, role changes, administrator profile updates. Site changes: plugin activation, deactivation and deletion, theme switches, WordPress core updates, and changes to key WordPress options (site title, admin email, permalink structure, etc.). Post and page editing activity is reserved for a future Pro version.

By default, log entries are automatically purged after 90 days via a daily WordPress cron event. You can change the retention period in Greenskeeper → Settings → Site Activity Log. Set the retention to 0 to keep entries indefinitely (not recommended for GDPR compliance). Entries can also be manually deleted individually or in bulk from the Site Activity page at any time.