How to monitor security updates across many Drupal sites

To monitor security updates across many Drupal sites, keep an inventory of deployed software, check advisories at least daily and route findings to an owner. Your options include Drupal Update Status emails, scheduled Composer audits, a self-hosted dashboard or a hosted service such as SentinelConnector. Combine repository checks with production reporting.

Last checked: 19 October 2026 (AEDT).

With a few sites, checking each Available updates report is manageable. Across dozens, the harder question is which production sites are affected, who owns the response and whether a quiet site has stopped reporting.

The Drupal Security Team normally publishes security releases on Wednesdays, 16:00–22:00 UTC, with exceptions outside that window. Subscribe to SA-CORE, SA-CONTRIB and PSA announcements, then connect those notices to your own inventory. (Release timing; announcement subscriptions.)

What monitoring needs to cover

Use these questions to assess any approach:

• Inventory: does it include every production site, with an owner and a current release identifier?
• Scope: does it assess Drupal core, contributed modules and themes, non-Drupal PHP libraries, or only some of these?
• Freshness: when did the site last report, and when were its versions last checked against upstream advisories?
• Action: where do findings go, who acknowledges them and what starts the patching workflow?
• Evidence: can you distinguish successful checks, known vulnerabilities and missing or incomplete results?

A PHP version field does not establish PHP-library advisory coverage. Likewise, a recently audited repository can contain a fix that production has not received. These distinctions determine what a dashboard can honestly tell you.

Option 1: Drupal core Update Status on each site

The Update Status module is Drupal’s built-in release checker. It provides the Available updates report for core and contributed projects, with checks and email notifications driven by cron. It is a useful free foundation, although each site remains a separate source of results. (Module overview.)

Open Reports → Available updates → Settings, at /admin/reports/updates/settings. Choose daily checking and notification addresses monitored by the maintenance team. Drupal supports daily or weekly intervals and a security-only notification threshold. Make sure cron actually runs and the emails reach their recipients. (Drupal user guide; settings reference.)

Drupal 11.2 renamed Update Manager back to Update Status after removing its legacy installation and management features. The machine name remains update. (Change record.)

Its limitations are operational: per-site emails do not assemble a fleet inventory, a response queue or a patching-history report. Each site or shared codebase needs a reliable check, with every production instance represented in the inventory. The module also sends anonymous usage information to Drupal.org, as its overview explains.

We recommend keeping it enabled as a per-site safety net, including when another tool supplies the central view.

Option 2: drush pm:security and its replacement

drush pm:security is a legacy command, not a current monitoring strategy. Drush removed it in favour of Composer audit; PR #5775 records that change, and the Drush command reference marks it as removed.

Search old CI definitions, maintenance scripts and runbooks for that command. Replace the check with composer audit, then verify its package scope, scheduling and failure handling. Updating the command name is only part of the migration.

Also distinguish an available newer release from a security advisory. Drupal’s Composer guidance uses composer outdated "drupal/*" for newer versions and composer audit for security-related findings.

Option 3: composer audit in each project or CI pipeline

Composer audit checks Composer-managed dependencies, including Drupal packages and non-Drupal PHP libraries. It fits an existing build pipeline and costs nothing to license. Drupal’s update documentation recommends it for security checks.

For the production dependency set recorded in a repository, run:

composer audit --locked --no-dev

The flags matter. Plain composer audit inspects installed-package metadata in the environment where it runs. --locked uses composer.lock regardless of the current vendor directory; --no-dev excludes development dependencies. Audit those separately if they are part of your build environment. (Composer CLI.)

Schedule checks daily as well as on builds. For machine-readable results on Composer 2.10.2 or later:

composer audit --locked --no-dev --format=json --no-interaction \
  > composer-audit.json 2> composer-audit.stderr

Run this as a dedicated CI step and retain both files even if it fails. Composer 2.10 changed normal audit results to 0 or 1; exit 1 can represent policy findings or a failed check. Review policy findings and failed checks separately. (2.10.0 changelog.)

A successful exit also depends on configured reporting and ignore policies. Review those settings and retain the last successful check time. (Composer configuration.)

Record the inspected commit or release. A lock-file audit describes that artefact, not necessarily production, and does not establish when a fix was deployed.

Option 4: a cron script across your repositories

A scheduled multi-repository audit centralises the Composer approach without buying a service. Drupal’s Securing your site guide includes a community example credited to @joelpittet: it finds Git checkouts, pulls changes, audits their lock files and uses cron email for output.

That is a useful starting point for a team with predictable repositories and an existing runner. We would adapt its error handling before relying on it. The published example selectively suppresses output, including a presumed network-error status. Silence can therefore hide an unsuccessful check.

Maintain an explicit site-to-repository list. Check the intended branch or deployment artefact, verify retrieval succeeded and retain each result with its site name and timestamp. Route unavailable repositories, missing lock files and invalid audit output to an operational alert.

This approach can collect many repositories into one report. Your team still maintains runner access, scheduling, email delivery and history. Reconcile the inspected commits with production, especially when a repository serves several sites or environments.

Option 5: self-hosted fleet dashboards

A self-hosted dashboard gathers data from connected Drupal sites into a central application you operate. These tools can provide production visibility when their companion modules run on production; that capability is not exclusive to hosted services.

• Multisite Status Dashboard, paired with Multisite Status Report, shows Drupal and PHP versions, update counts, cron status and check failures. Requests use HMAC signatures. “Core-only” describes its dependencies, not a restriction to checking Drupal core: the Report module exposes enabled-project update information.
• Status Dashboard, with Status Dashboard Client, monitors core and module updates through cron. It supports email notifications with daily, weekly or monthly schedules and selectable update categories.
• Site Guardian exposes core, module, PHP and status information through key-protected JSON. Its separate dashboard aggregates sites, and a PDF Report companion generates reports. Assess each component of that stack separately.
• Warden combines a Drupal module with a separate server. The server documentation includes email and Slack alerts. Its Drupal project currently lists maintenance fixes only, so check the available release against your Drupal version.
• Drupal Remote Dashboard (DRD) uses DRD Agent for remote monitoring and management. Its 4.1 branch supports Drupal 10 and 11. Choose it when its wider administration capabilities fit your operating model.

The software is free to obtain; hosting, access control, updates and recovery remain your responsibility. Check maintenance status, release compatibility and security advisory policy coverage for both dashboard and connector. A project’s coverage does not automatically extend to its companions.

Option 6: a hosted fleet service

A hosted fleet service moves central application operation to a provider. Check how it collects inventory, which advisory sources it uses, how it handles missing data and whether the reports answer your customers’ questions.

SentinelConnector is our option in this category. Its Drupal module sends installed core and module inventory to the service, which matches project and version information against Drupal.org evidence. Connected sites appear together for the selected organisation. (How SentinelConnector works.)

The value is the workflow around those observations: a shared view, explicit assessment coverage, alerts and, on paid plans, patching targets and monthly reports. You still own updates and production verification.

Do not assume that any fleet product covers arbitrary Composer libraries. SentinelConnector’s public documentation describes core and module assessment; it does not yet establish general non-Drupal PHP-library coverage (this new feature is in development). Keep Composer audit alongside it for now.

Comparison: which approach covers what?

“Not documented” means the reviewed sources do not establish the feature. It is not a claim that the feature is impossible. Production visibility depends on connecting the production environment.

Project links and documentation appear in the relevant sections. SentinelConnector’s Help, features and pricing describe its alerts and plan boundaries.

How to monitor many Drupal sites with SentinelConnector

Requirements: Drupal ^10.3 || ^11, PHP 8.3 or later, Composer access, and permission to enable modules and edit environment settings. These requirements exclude Drupal 7/9 and PHP 8.2. Check the Drupal.org project page. The project must have the Drupal Composer repository, https://packages.drupal.org/8, configured.

Step 1: Register your site

Create an account and complete organisation setup. Confirm your email when prompted before adding the first site. Free supports one site without a card; choose a paid plan when you need more sites or reporting.

In Sites → Add New Site, select the organisation, name the site and enter its full production URL. An organisation administrator creates a key in API keys. Copy it while it is shown. We recommend a separate key for each site.

The listed monthly plans are Free at A$0 for one site, Solo at A$29 for three, Studio at A$99 for ten and Agency at A$249 for fifty total. Prices are in Australian dollars, plus applicable tax; Enterprise capacity is agreed separately. See current pricing and terms.

Step 2: Connect Drupal

Follow the installation and connection instructions. Add the module through your normal deployment workflow:

composer require 'drupal/sentinel_connector:^1.0'
drush en sentinel_connector -y

Open Configuration → Web services → Sentinel Connector, at /admin/config/services/sentinel-connector. Copy the API base URL, Site UUID and Site URL from the site's Connection tab. Use the base URL, not a full sync endpoint. Keep report scope at all unless you deliberately need exclusions.

Keep the key in production’s private settings.php using $settings['sentinel_connector.api_key'], or in SENTINEL_CONNECTOR_API_KEY. The form’s Drupal state storage is another option, but is not encrypted.

Before enabling scheduled reporting, apply the project’s production-only configuration guidance after other settings includes:

// Adapt APP_ENV to your host's trusted environment identifier.
$sentinel_is_production = getenv('APP_ENV') === 'production';
$config['sentinel_connector.settings']['enabled'] = $sentinel_is_production;

if (!$sentinel_is_production) {
  $config['sentinel_connector.settings']['api_base_url'] = '';
  $config['sentinel_connector.settings']['site_uuid'] = '';
}

APP_ENV is an example, not a Drupal standard. Configure it consistently for web requests and Drush/cron. Missing or non-production values keep reporting off. Clearing the URL and UUID also blocks manual pushes from database clones; disabling cron alone does not.

Rebuild caches after settings changes and verify the effective configuration:

drush cr
drush config:get sentinel_connector.settings --include-overridden

Confirm non-production has reporting disabled and empty API URL and Site UUID. Then, on production, send the first inventory:

drush sentinel_connector:sync

Sync now on the settings form is an alternative. Check Drupal’s status report and the site’s recorded submission.

Step 3: Review your websites

Use Dashboard and Sites to review findings alongside coverage and freshness. Complete describes assessed observations; Partial means some could not be assessed; Unknown, Stale and Failed need follow-up. No usable data is not a clean result.

Open Updates for advisories, severity and available fixed-version evidence, and Releases for observed changes. Review TLS certificate information where enabled. Check security email delivery to eligible recipients when the email service is enabled. For optional Slack alerts, connect the workspace and link your Slack account under Settings → Integrations. Invite the Sentinel bot to the intended channel, then select and save that channel for the site. Assign an owner to act on findings. (Capabilities; Help.)

Inventory submission and advisory assessment have separate schedules. Cron sends changes with a daily refresh when unchanged; Free accepts one submission per 24 hours and paid plans up to hourly. Manual sync still respects those limits. The service also reassesses reported changes and checks on weekday mornings, with extra checks during Drupal’s weekly security window. Read both timestamps. (Module; check frequency.)

Paid plans support a patching SLA from six hours to 28 days and monthly reports. This measures your team’s target. The service does not install updates or monitor uptime. Custom code and observations without reliable metadata remain unassessed. Retain deployment records: an observed fix or later confirmation does not prove its installation time.

Which approach should you use?

For one to three sites, we recommend starting with Update Status and scheduled Composer audit. That is an operating suggestion, not a limit of either tool.

For many sites maintained by one team, a repository audit runner or self-hosted dashboard may be enough. Choose according to whether you need dependency checks, live-site inventory or both, and assign someone to maintain the monitoring itself.

When you manage customer organisations and report against patching commitments, evaluate a hosted service with the required access and reporting features.

Start with one representative production site. Confirm an initial inventory, a scheduled refresh, notification delivery and the path from a finding to a ticket. Then roll out across the fleet and reconcile the site list. Keep Update Status, Composer audits and the central view working together.

Frequently asked questions

How do I check for Drupal security updates on multiple sites at once?

Use per-site Update Status emails, scheduled Composer audits across repositories, a self-hosted fleet dashboard or a hosted monitoring service. Keep a complete site list, distinguish repository versions from deployed versions, and send both security findings and unsuccessful checks to someone responsible for acting.

Source: Drupal monitoring and audit guidance.

What replaced drush pm:security?

Composer audit replaced the removed Drush pm:security command. Update older CI jobs and maintenance scripts, then check the Composer options and result handling. A command replacement alone does not add fleet reporting or confirm what is installed in production.

Source: Drush legacy command reference.

Does composer audit check Drupal modules?

Yes. It can check Composer-managed Drupal packages and non-Drupal PHP libraries against available advisories. By default it audits installed-package metadata; --locked selects composer.lock instead. A repository audit does not necessarily represent production. Review configured policies and investigate failed or incomplete checks.

Source: Composer audit options.

Should I keep Update Status enabled if I use a monitoring tool?

We recommend keeping it enabled as a per-site safety net. Configure a monitored notification address and working cron, and choose daily checking where that matches your policy. This recommendation does not establish whether a particular fleet connector depends on the module.

Source: Drupal update notification setup.

Is there a free way to monitor many Drupal sites?

Yes. Update Status, scheduled Composer audits and self-hosted dashboards can monitor many sites without a software licence fee. You provide scheduling, hosting where needed, maintenance and follow-up. SentinelConnector Free supports one site, so it is a starting point rather than a free multi-site plan.

Sources: Drupal’s monitoring guidance; DRD; SentinelConnector plan limits.

How often should I check for Drupal security updates?

We recommend at least daily checks and additional attention during Drupal’s Wednesday UTC security release window. For online services in scope of ISM-1698, daily vulnerability scanning is required. Check inventory freshness and advisory-check freshness separately; receiving no email does not prove that either check succeeded.

Sources: ISM-1698; Drupal release timing.

For Australian government teams, TrueCMS’s GovCMS PaaS 48-hour patching runbook explains the response deadlines, deployment workflow and evidence to retain.

How do I install SentinelConnector?

Install drupal/sentinel_connector with Composer, enable it with Drush, and configure the connection values and a private API key. Apply the production-only settings before scheduled reporting, then run drush sentinel_connector:sync on production. Confirm that inventory arrived and an assessment completed. The three-step walkthrough above includes the commands.

Source: Sentinel Connector installation and configuration.