Delete a site

Organisation admins and site managers can delete a site. Viewers do not see Delete site, and Sentinel refuses the request if they try another way. Open the site, select the Setup tab, and use the Delete site card. Check the site name and address in the confirmation, then select Delete site again, or Cancel to keep it. If your account uses two-factor authentication, you are asked for a current code first. When the site is deleted, Site deleted appears and you return to the Sites list. If the deletion is refused, the reason shows in the dialog and the site is unchanged.

Deleting a site stops its monitoring, and its Connector can no longer send updates. The site is removed from Sites, dashboards and new reports for everyone in the organisation. Reports already issued keep it. You cannot restore a deleted site from the dashboard; contact Sentinel support if you need it back. Platform administrators do not change sites from these customer pages; they use the administration console.

Do not treat a missing list result as deletion. Check the selected organisation and search first.

Install the Sentinel Connector module

You need access to the Drupal project, Composer, and permission to enable modules and edit Drupal settings. The published Connector requires Drupal ^10.3 || ^11 and PHP >=8.3. Use the project's normal deployment process when making these changes to a live site.

The package is drupal/sentinel_connector on Drupal.org. Your project must include the Drupal Composer repository, https://packages.drupal.org/8. Projects created with drupal/recommended-project already include it; otherwise follow the Drupal Composer setup guide. From the Drupal project directory, install the supported release:

composer require 'drupal/sentinel_connector:^1.0'

Enable the module with Drush:

drush en sentinel_connector -y

Run these through the project's normal Composer and Drush environment. If Drush is unavailable, ask the site maintainer to enable the module and complete configuration. Installing the package alone does not connect the site.

Connect Drupal

Open the site's Setup tab. It gives four short steps with this site's values, and links the knowledge base article "Use the Sentinel Connector on several environments" for anything beyond one environment (while the knowledge base is off, the link opens this guide).

1. Install and enable Sentinel Connector in Drupal with the displayed commands.
2. Copy the Site UUID into Drupal's Configuration → Web services → Sentinel Connector settings at /admin/config/services/sentinel-connector. Connector 1.4.0 and later need no Sentinel address and no site URL: the module sends to Sentinel production by default. On a Sentinel that is not production, Setup also shows this Sentinel's API base URL to set in settings.php ($settings['sentinel_connector.api_base_url']) or the SENTINEL_CONNECTOR_API_BASE_URL environment variable.
3. Have an organisation admin or site manager add a key for this site in Connector keys: create a new key and copy it while it is visible, or choose an existing key that you already use on another site. We recommend a separate key for each site. Store the key with the Key module, $settings['sentinel_connector.api_key'] in settings.php or the SENTINEL_CONNECTOR_API_KEY environment variable.
4. Test the connection with Test connection on the Drupal settings form or drush sentinel_connector:check, then send the first inventory with Sync now or the displayed sync command.

drush sentinel_connector:check
drush sentinel_connector:sync

The check asks Sentinel whether the address, key and Site UUID in use work and which Sentinel answered. It stores nothing and does not count against the plan's push limit. "Site UUID not known here" usually means a production UUID on a non-production environment, or the other way round.

In the module you also choose the Report scope (All: Drupal core, contrib and custom modules; or Drupal core and contrib, which leaves custom modules out), Report configuration drift, and Report platform versions (web server, database and operating system versions; on by default). The PHP version is always sent, because Drupal core support depends on it.

Several environments. The Site UUID, API key, Sentinel address and an off switch ($settings['sentinel_connector.disabled'] or SENTINEL_CONNECTOR_DISABLED) can each come from settings.php or an environment variable, so one codebase can send production and non-production as two Sentinel sites and send nothing from local and CI. The module ships an example include file, settings.sentinel_connector.php. The knowledge base article has the details.

What this site reports. After a push, a panel on Connection shows the report scope, whether platform versions are shared (with the date sharing was turned off), and the connector version with any newer release. A connector older than 1.4.0 does not report these choices; the panel says so.

Drupal cron must run for subsequent submissions. The Connector sends on cron at most once an hour, subject to plan limits. Sentinel does not install Drupal updates from the dashboard. Apply updates through your normal Drupal maintenance process and send a new inventory afterwards.

Connection distinguishes Never connected, data received without an assessment, assessment in progress, assessment failed, and assessed. An accepted submission confirms receipt of inventory only.

If a module's version cannot be read, for example a Composer branch name such as dev-main, Sentinel still accepts the inventory. That module is stored with an unknown version, the same as a module whose info file has no version, so its security status is Unknown and it keeps the site Partial until a readable version is sent. Spaces around a version are removed. Only a malformed module machine name refuses the whole submission; nothing from that submission is stored.

If a new site has sent no data once the alert delay has passed since it was added (24 hours by default; Sentinel checks every 15 minutes), Sentinel sends a has sent no data since it was added alert. Usually the Sentinel Connector module has not been installed or connected yet. The email links back to this section for installation and setup instructions.

The five site tabs

The site page has these tabs: Overview, Updates, History and Setup.

The address keeps the tab, so you can bookmark it. Old addresses such as ?tab=summary, ?tab=modules, ?tab=stack, ?tab=releases, ?tab=drupal-configuration and ?tab=connection still work: they open the matching new tab, so old emails and bookmarks keep working.

The header shows the site name with its status, then one line with the address, Drupal version, PHP version and last sync. Open site opens the site in a new browser tab. Get help with this site shows while the support portal is available and starts a support request for the site. Above the header, a path reads Sites / [site name]. Select the site name to open Switch site, a list of your organisation's sites; picking one opens that site on the same tab. Edit, delete and back actions are not in the header: use the Setup tab, or Sites in the path.

All modules. On the Updates tab, the All modules chip (address ?tab=updates&list=modules) searches the reported inventory and filters it by status, type, and enabled state. The list opens on Contributed modules; select All types in the Type filter to also see Drupal Core, custom, and untyped modules. Review installed and recommended versions. Installed marks an alpha, beta or release candidate with Pre-release and a development snapshot with Dev; Not reported means the site sent no version. Recommended shows Up to date in green when nothing newer is published, or the newer release: red for a security update, amber for a maintenance update. A recommended release can be one Drupal.org's security team does not cover; it then says Not covered by Drupal security team. A site on a stable release is only offered stable releases. A site on a pre-release is offered the newest stable release if one is out (Stable release now out), otherwise a newer pre-release (Newer pre-release). Development snapshots are never recommended. Status reads Security update, Known vulnerability, Maintenance update, Current, Unsupported, Dev build, Custom or Can't check; Can't check gives its reason, such as Site did not send a version or Not checked yet. Security reads Known vulnerability, No known advisory, Not covered (no Drupal.org security team cover, so no advisories are issued for it) or Can't check. Current and Up to date need a current assessment; an older one shows Can't check with Assessment out of date. Drupal Core is grouped in one row. Sub-modules are not listed: a module is shown as enabled when it or one of its sub-modules is enabled.

The Overview tab

The Overview tab answers "is this site safe, and what should I do next?" from the top down.

• Verdict: a dark card with one line such as "No vulnerable Drupal.org components. 2 components to update." It counts affected Drupal.org components, not advisories, and leaves out PHP, web server and database matches, which show on Platform and in the Platform list on the Updates tab. The ring shows the share of reported extensions that Drupal.org could check. When some were not checked, the line below says the counts are a minimum. With no usable counts it says "Security status cannot be confirmed yet." The Security, Coverage and Freshness pills match the strip shown on the other tabs. Review updates opens the Updates tab when there is something to apply, and See what is unchecked jumps to Drupal.org coverage.
• Counts: Known vulnerabilities, Outdated components and Extensions checked (checked out of all reported, then Assessed, Partial assessment or Unknown). The green shield appears only when a complete, current check found no vulnerable component; an unknown or minimum count shows a grey shield.
• Platform: the Drupal core, PHP, web server and database versions. Select See platform details to open the Platform list on the Updates tab.
• Health checks: each row shows its label on the left and its value on the right. The TLS certificate comes first; select it to see its details. Then Last check, Last sync, Connector, Patching SLA and Modules enabled. When no patching SLA is set, organisation administrators can select Set SLA to open the Edit site form (on the Setup tab). The row is left out when your plan has no patching SLA.
• Drupal.org coverage: the extensions Sentinel cannot fully vouch for, grouped by reason with a count beside each. Select See these extensions to open the All modules list on the Updates tab.

Connector update icon. On Overview, a red information icon next to the Connector version means a newer Connector is available. Hover over it or move keyboard focus to it, or click or tap it, to read "An updated connector version with new capabilities is available." The icon also shows when a site that has synced reports no Connector version. Nothing shows when the version is current or the site has never synced. To clear it, update the Connector with Composer (composer update drupal/sentinel_connector --with-dependencies), deploy, run the database updates (drush updb -y), then run drush sentinel_connector:sync. The icon disappears once the site reports the new version.

Inventory is loaded in pages; use Next inventory page and Previous inventory page when offered. A filter on loaded inventory does not prove that unloaded pages have no matching modules.

The Platform list

Open a site, select Updates, then the Platform chip in Update lists (the address ends ?tab=updates&list=platform). It shows the versions of the site's PHP, web server and database and the known vulnerabilities (CVEs) those versions match. The wording is always "matches known vulnerabilities", never "is vulnerable": Sentinel checks the version number, and hosting providers often fix a problem without changing it. Matches that are probably vendor fixes (low confidence) are never shown.

• Metric cards: four cards sit above the Stack card: Open matches, Known exploited, Marked not affected and Components checked (for example "2 of 3"). Open matches, Known exploited and Marked not affected read, for example, "0 minimum" while any component has no version check or may have matches held back. Matches can be held back when your vendor may have fixed the problem without changing the version number, even with Sentinel's Ubuntu and Debian checks on, because a vulnerability the vendor has not ruled on stays hidden. Components the site owner stopped sharing count as not checked. The cards show counts, not an all-clear, because a version check cannot prove a component is safe.
• Stack card: one row for each component with the columns Component, Version, Source (Reported by the Connector, Declared in Edit site, or Unknown), Last seen and Open matches by severity. There is no separate Fixed in column: when a fix version exists, "Fixed in [version]" shows under the open matches, and the number marked not affected sits there too. Products Sentinel does not match, such as LiteSpeed, Microsoft IIS, Caddy or SQLite, show Not checked yet. A managed or forked database build whose version cannot be matched, such as Amazon Aurora MySQL or Percona Server, reads like a version that was not reported (see No version below); declaring a version does not help while the Connector reports one.
• No platform data reported: when the site owner turns off Report platform versions in the Connector, the web server and database rows are replaced by a grey panel: web server, database and operating system versions are not checked and no stack alerts are sent; PHP is still reported by Drupal and checked. Versions reported before then are kept for the reports that cover those dates and are no longer shown here. Open matches leave the counts without being called resolved, and show again if the same version is reported again. On Overview, Platform shows Not reported for those components.
• No version: the row reads "[Component] version not reported. Add it in site settings to check it." Organisation admins and site managers get a link that opens Edit site (see Stack versions). Viewers read "An organisation administrator can add it in site settings to check it."
• What this means: a link to the knowledge base article "What 'matches known vulnerabilities' means", shown only while the knowledge base is available. The article also explains how to confirm a match with your host, using its security notices or the package changelog.
• Known vulnerabilities table: for each match, the CVE and title, the component with the matched version stacked beneath it, the severity with its CVSS score, a red Known exploited badge (CISA Known Exploited list) under the severity, shown only when it applies, the published date, the version it is fixed in, the status (Open, Not affected or Resolved), and Vendor and NVD links. Filter by component, severity (including Not scored) and status. The table shows 25 rows a page; use Previous and Next. The number of matches sits beside the title. A site with no matches at all shows "No known vulnerabilities match the checked versions." and "This is a version check. It does not prove the whole site is secure.", and the filters and table are hidden. Filters that match nothing show "No known vulnerabilities match these filters." with a Clear filters button.
• Ubuntu and Debian checks: these appear only when Sentinel turns on its Ubuntu and Debian checks. Ubuntu and Debian often fix a problem in a new package build without changing the version number. For a component installed from Ubuntu or Debian packages, Sentinel then reads that vendor's own security data for the exact package build. On the Stack card, under the source, one line says how the component was checked:
  • "Checked against Ubuntu 24.04 security data, package [build]": the vendor's data was used for that build.
  • "Checked against Debian 12 security data by version number": the server named only its operating system, not the package build (Debian's Apache does this). The vendor's data can confirm a problem but cannot confirm a fix.
  • "Ubuntu 24.04 security data is out of date: earlier results kept": Sentinel could not refresh the vendor's data. Earlier answers stay, and nothing new is decided until it refreshes.
  • "No Ubuntu 24.04 security data yet: version check only": Sentinel has no data for that release, so the usual version check applies.
  • "Runs on Ubuntu 24.04, but the package build was not reported: version check only": the site runs on that system but did not say which package build it has. A newer Sentinel Connector can send the build.
• Ubuntu and Debian answers in the table: under Fixed in, a line gives the vendor's answer: Fixed by Ubuntu (your build has the fix), Ubuntu fix available (a newer build fixes it), Fix needs Ubuntu Pro (the fix is only in Ubuntu Pro, for older releases such as Ubuntu 20.04), No Ubuntu fix yet, or Debian: not affected. Debian reads the same way. Fixed in then shows the vendor's fixed package build when there is one. A link named Ubuntu or Debian opens the vendor's page for that CVE. A match the vendor says is fixed in your build becomes Resolved by Ubuntu (or Resolved by Debian), and one it says is not affected becomes Resolved: Ubuntu not affected (or Resolved: Debian not affected); the Status filter still lists both as Resolved. One already fixed when first checked is never listed. A match the vendor says is not fixed in your build shows even when Installed from operating system vendor packages is ticked or the version carries a package build. A Not affected mark stays on a match the vendor resolves, and applies again if the match comes back at the same version, unless the severity rose or it was added to the Known Exploited list.
• Download the list: Download CSV and Download PDF, at the top right of the Known vulnerabilities section, save every match that fits the current Component, Severity and Status filters, not only the 25 rows on screen. With all filters on All, the file holds everything. The buttons appear only when at least one match fits, and every member who can open the site can use them, viewers included. The CSV (times in UTC) suits spreadsheets; the PDF is a landscape A4 report that shows the site, the filters used, the count and when it was made, in your time zone. Low-confidence matches are never included. Files are named like example-site-known-vulnerabilities-2026-10-26.csv. While the Ubuntu and Debian checks are on, the CSV also ends with two columns, Distribution verdict and Distribution page, and the PDF shows the vendor's answer under Fixed in with a link to the vendor's page. Platform administrators see the same buttons on the admin console's site page.
• Mark a match as not affecting the site: organisation administrators and site managers see a checkbox and Not affected on each open row. Choose a reason: patched by the hosting provider or operating system vendor, the affected feature or module is not used, mitigated another way, or other (a note is then required). A note is optional for the other reasons and can be up to 1,000 characters. To do several at once, tick rows and select Mark selected not affected; the select-all box covers the open rows on the page. If a row changed since the list was loaded, it is skipped and the message says so.
• Marked matches: the row shows who marked it, when, the reason and the note. Withdraw makes it open again. A new vulnerability, or a new version of the component, shows again: marking a match never covers a different CVE. A match marked not affected also reopens when the vulnerability's severity rises to a higher band or it is added to the CISA Known Exploited list. If the component changes to a version that no longer matches, the match becomes Resolved instead.
• Read-only members: viewers see the table, including who marked a match and why, but no checkboxes, Not affected or Withdraw.
• Ticket column: when ticket links are on for your organisation, the table has a Ticket column and Link ticket (N). See Ticket links.

Matches come from the NVD, the CISA Known Exploited list and vendor security pages, which Sentinel updates daily. Marked and low-confidence matches do not raise alerts (see Known vulnerability alerts). The tab is available on all plans. No match does not prove the site has no known vulnerabilities.