Open Messages or use the message bell. Choose All my organisations or Current organisation, then filter by severity and open or resolved status. Load older messages when needed.

Open the related site link to investigate a site alert. You can mark a message read or unread, mark all messages read, and acknowledge messages that offer that action. Reading or acknowledging a message records your response. It does not fix the site condition.

Critical messages can open a dialog. Remind me later delays the popup; it does not resolve the issue. Acknowledge records that you have seen it. Resolved notices are separate from open alerts.

Security alerts on release day

A security alert tells you that a Drupal security release affects one of your sites. This section explains when it arrives, who receives it and how to manage it. The next section, Security update alerts, explains how an alert opens and closes.

When it arrives. Drupal publishes security releases on Wednesdays, US time, which is usually Thursday morning in Australia (Melbourne time). Sentinel emails as soon as it has confirmed that an advisory affects the installed version a site reported. It checks for new confirmed findings every minute, but it can only alert after the advisory has been collected and the site's reported version has been assessed, and email delivery adds a little more time. So the email may arrive some time after the release, and Sentinel does not guarantee a delivery time. No alert is not proof that a site is secure; check the assessment age on the site.

What the email contains. The subject is Security update needed for [site name]. When one check finds alerts for several websites, you get one email for the organisation and the subject reads, for example, "3 websites need a security update". You get one email per organisation, not one per site or advisory. Each site appears once, with the modules that need updating and a coloured badge for its worst drupal.org risk level (Highly critical, Critical, Moderately critical, Less critical or Not critical). Its Open link opens the site's Updates tab. A last row counts your organisation's other sites: Up to date means the site reported data within the stale-data window and has no open security finding, and Updates still needed means it still has an alert from an earlier email. Websites that are quiet or have never sent data are not counted. Below the list, Modules affected names each module, its risk level, the kind of problem, how many of the listed sites it affects and a link to the drupal.org advisory. If the same email also carries other website notices, such as a certificate expiring, the subject reads "[number] website updates for [organisation]" and those notices follow the security list. Sign in with an account that still has access to the site.

Why it cannot be turned off. Security alerts are required notices. Rules in Settings (Notification rules), quiet hours and personal email choices cannot suppress or delay them. The only control is who is in the audience, set by an organisation administrator.

Choose the audience. An administrator chooses one of two settings:

Email all members: every member of the organisation with a verified email address gets security alerts and cannot turn them off.
Email administrators only; members can opt in: administrators always get them. Other members get them only if they opt in.

The first choice is offered when you create an organisation, on the Choose who gets security alerts step (see Optional security alerts step). Change it later in Settings → General with Security alert audience: email all members: on means all members, off means administrators plus members who opted in. A new organisation starts with all members.

How members opt in. In Profile, open Email preferences. For an organisation that emails administrators only, tick Email me security alerts. Where all members are emailed, or you are an administrator, the card shows Always on instead. Members who are not administrators in such an organisation are also asked once, on the dashboard, Get security alert emails?, with Email me security alerts and Not now. See Profile and general Settings for details. An opt-in belongs to one organisation, and it ends if you are removed from that organisation.

Add Slack. Slack can carry the same alert to a channel, in addition to email. Connect the workspace in Settings → Integrations, then choose a channel for each site in Edit site. Security update notices do not need Include administrator-only notifications. Observed release and confirmed-fix emails are not sent to Slack. See Workflow integrations for the steps.

If someone did not get an email. Check these in order:

Unverified address: the person has not verified their current email address, or changed it and has not verified the new one. Alerts still appear in the dashboard.
Not in the audience: the organisation emails administrators only and the person is a member who has not opted in.
Removed from the organisation: a person who is no longer a member is not emailed, and their opt-in is deleted.
Finding not confirmed: Sentinel alerts only when the reported installed version is confirmed as affected. A project-name match alone does not send an alert, and the alert is withdrawn while the site's latest assessment shows it is no longer affected.
Site paused or inactive: paused or deleted sites, and inactive organisations or clients, are not alerted.
Email disabled for the service: the alert still appears in Messages. If email is enabled again while the finding is still open, it can be sent then.
Already alerted: Sentinel sends one email for the same open finding. A person added afterwards does not receive the earlier alert, and the same finding does not email again until it has been resolved and found again.

How this differs from weekly summaries. A security alert is sent for a release as soon as it is confirmed, while a weekly maintenance summary is a digest on Monday at 09:00 in the organisation owner's time zone. Security alerts are required and have no personal opt-out, while the weekly summary is enabled by an administrator for each organisation and each person can clear Email me this organisation’s weekly summary. A weekly summary does not replace an alert, and an alert does not change the weekly schedule.

Security update alerts

Security update needed for [site name] means Sentinel has confirmed that an advisory affects the reported installed version. Select Open Updates to review the advisory and the site's Updates tab. These critical messages are available to all organisation members on every plan. A project-name match without confirmation that the installed version is affected does not send this alert. If later evidence cannot confirm the affected version, an earlier confirmed alert can stay open; uncertainty does not prove resolution, and no pending security email is sent until confirmation returns.

Sentinel checks for these alerts every minute after a finding is recorded. Advisory collection, site inventory, assessment processing, and email delivery can add time. An advisory published on Drupal.org does not cause an immediate email. Existing open confirmed findings can also trigger an alert when this service first runs. No alert does not prove that a site is secure; check assessment age and coverage.

When email is enabled, new security alerts are grouped into one email per recipient and organisation for each check, with each site listed once. Who receives it, and why someone might not, is explained in Security alerts on release day. All members still see the dashboard messages. Each person controls their own confirmed-fix and release emails, and the security alert opt-in where it applies, in the Email preferences card in Profile. Settings provides organisation notification rules, which cannot suppress security alerts.

Repeated checks do not send another email for the same open finding. If email is temporarily disabled or there are no eligible recipients, the alert can be emailed later while the finding and its site remain active. Adding a recipient after an alert email has already been queued does not send that old alert again.

After Sentinel records a finding as resolved, the next alert check closes its message. The security alert itself sends no resolution email; a confirmed fix can be announced separately, as described in the next section. If the latest assessment shows the site is no longer affected but Sentinel has not yet closed the finding, the finding stays open on the site while the next alert check closes its message, and no security email is sent for it. If later evidence shows the site is affected again, a new alert and email follow. Pausing a site also closes its alert without proving that the update was applied. Resuming a site with the finding still open, or detecting the finding again after resolution, can raise a new alert. Reading or acknowledging a message does not change the finding.

Known vulnerability alerts

Sentinel compares the PHP, web server and database versions of a site (reported by the Connector or declared in Edit site) with published vulnerability data. When the site matches known vulnerabilities that are serious, Sentinel raises an alert. A match means the version is listed as affected. It does not prove the site can be attacked, because some vendors fix problems without changing the version number.

When it runs: after the Connector reports a changed PHP, web server or database version, after you save declared versions, and after each daily update of Sentinel's vulnerability data. After each update, you get one email per organisation covering all its affected sites.
What is serious: a vulnerability with a CVSS score of 7.0 or higher, or one on the CISA Known Exploited list at any score. Nothing below 7.0 raises an alert.
One alert per site: each check sends at most one message for a site, listing what is new, has come back, or has become more severe. The message lists up to ten CVE numbers, most serious first, and counts the rest.
Severity: [site name] matches critical known vulnerabilities (critical) when any listed item is CVSS 9.0 or higher or Known Exploited. Otherwise [site name] matches known vulnerabilities (warning).
Open the site: the message links to the site's Platform list (the Updates tab). Each alert is a one-off notice in the message bell, so it does not appear in Waiting on you.
Not alerted: matches you have marked as not affecting the site, and low-confidence matches for components installed from operating system vendor packages. When Sentinel turns on its Ubuntu and Debian checks, a serious match that Ubuntu or Debian says is not fixed in your build is alerted, except for matches found the first time the checks run. Matches the vendor resolves are not alerted. If a match you marked as not affecting the site is reopened, or a match becomes more severe, Sentinel alerts again.
Cannot be turned off: these are required notices, so Settings notification rules do not switch them off. They go to the message bell, to Slack channels and signed webhooks set up for the website, and to the website-updates email for the same people as other website alerts, as set by Email website alerts to all members. Email is sent only where the Sentinel service has email switched on.

These alerts are available to all organisation members on every plan. As with other alerts, no alert does not prove a site has no known vulnerabilities.

Confirmed fix and release emails

Sentinel can also tell you when it confirms a security fix or observes a release on a site. These messages are available only where the Sentinel service has switched them on. When they are on:

Release observed on [site name] means an accepted inventory showed new versions of Drupal core, a module or custom code. No email is sent for a deployment of only additions or removals. It lists the old and new versions and when Sentinel observed them. It is not a statement that a deployment finished, and Sentinel is not told which environment reported it.
Security fixes confirmed lists each advisory fixed by a version update, the versions involved, when the change was first seen in an accepted inventory and when Sentinel confirmed it. Times are in your time zone. Where your plan includes the security patching SLA and the site has one, each fix says whether it was within or after the SLA; otherwise the email says why no SLA result is given.
A release and the fixes confirmed for it shortly after can arrive as one email, according to your email choices. A fix confirmed later can arrive as a follow-up. Grouping, assessment checks, quiet hours and delivery delays can affect when an email arrives.
These emails list only confirmed changes. They do not mean a site has no other security issues; they list any remaining open advisories by count when the email was prepared and say when the confirming check did not cover every component. A removed module is not reported as a fix.

A summary appears in Messages for organisation members, including readers and site managers. If message email is disabled for the service, the summary still appears, but these emails are not sent later when email is enabled again. Email goes to administrators, or to every member when Security alert audience: email all members is on. A member's security alert opt-in does not add them to these emails, and in an organisation where only administrators receive them, members cannot receive these emails at all. Only people who have verified their current email address receive them. Sentinel checks each recipient again just before sending, so someone who has left the organisation, changed their address or turned these emails off does not receive one, and a fix that Sentinel has since found again is not sent. Recipients choose Confirmed fixes and New releases seen on your sites in the Email preferences card in Profile. These choices do not change new security alerts or monthly and weekly schedules.

Default notices are available on Free and paid plans when enabled. Custom rules need report access; if that access ends, an event type with saved rules is suppressed. They are withheld if the site, organisation or assigned client is no longer active, the site moves to another organisation, or the subscription is overdue, unpaid or paused. Changes reconstructed from old records do not send these notices.

Select Open release in the email to review its Releases details, or Open Updates for a fix without a linked release. Sign in with an account that still has access to the site. Release history limits still apply. The email describes evidence at the time it was prepared; the dashboard shows the current state. If an observation time is unavailable, the email says so and gives no SLA result for that fix. A confirmed fix does not erase an earlier SLA breach.

Weekly maintenance summaries

Where weekly summaries are enabled, open the organisation details page and find Weekly summary. This section requires an active organisation administrator, a verified current email address and report access on an eligible plan. A covered Agency organisation uses its holder's plan and its own administrators. Ordinary members cannot open the preview or delivery history, including TLS details.

Select Enable weekly summaries for this organisation to start the schedule. The next summary is scheduled for Monday at 09:00 in the organisation owner's time zone. The owner sets it on their Profile; an owner with none uses UTC. It covers the previous Monday to Monday. If sending is delayed, it can recover until Tuesday at 00:00 local. Missed weeks are not sent later. Enabling again or a change to the owner's time zone starts with the next Monday slot.

Email me this organisation’s weekly summary controls only your weekly emails for this organisation. It is on by default and takes effect when the organisation enables its schedule. Clear it to stop your weekly emails. This does not change immediate website alerts, confirmed-fix notices or monthly report choices.

When the service has turned configuration drift on, the summary also has a Configuration drift section after the security figures. It lists sites that had drifted at the cutoff (name, number of differing objects and when drift started), sites whose drift state is unknown, and drift that cleared during the week. When nothing had drifted it says "No configuration drift at cutoff." The section is absent while the feature is off, and drift is not in the monthly report.

The Read-only preview does not send an email. Fix activity covers the closed week; open findings, available updates and TLS details describe evidence at the shown generation cutoff. Unknown, partial or outdated results are not a healthy result. Known counts can be lower than the actual total. A week with no confirmed fixes can still have open security work or missing data. Fixes after their SLA deadline remain separate. TLS uses stored checks; an old valid check does not prove that the certificate is valid now. Source and collection location can be unavailable.

Delivery history shows provider acceptance, failure, uncertain delivery or why a summary was not sent. Provider acceptance does not prove inbox delivery. Each saved week shows the time zone used when its summary was generated, including after the owner changes their time zone. An uncertain email is not sent again automatically. Frozen weeks do not change when later evidence arrives, and there is no resend control. Current site links require sign-in and show current data. If saving or loading fails, use the shown retry control and check the saved state before changing it again.