Open Reports. Reports show monthly security patching results and the evidence for each site. Select a year and month. If the organisation has client groups, select a client to limit the report to that group. A client group is a report filter, not a separate dashboard membership boundary.

Summary and site reports

The sites list beside the report starts with Summary, followed by each site in scope. On a narrow screen, select Change site to open the list. When there are more than eight sites, use Find a site to search by name or address. Selecting a client narrows both the summary and the list.

Summary shows a row of headline figures, two charts and a scoreboard of all sites in scope. The summary is a dashboard only: it cannot be printed from the page, downloaded as a PDF or issued.
A site report opens with one result block, then the site's check-in details, its results and its deployment ledger. This is the report you print, download, issue and add notes to.

The headline figures are Sites met SLA, Security updates, Typical time to patch, Outstanding at month end (Outstanding now for the running month) and Maintenance changes. Maintenance within SLA appears only when a site in scope has a maintenance target. The two charts show security updates within SLA by month and security updates by risk level.

The printed or issued report shows its own tiles: Sites that met SLA, Security updates applied, Applied within SLA, Typical time to patch, Deployments, Maintenance updates applied, Security updates outstanding now (at month end for a finished month) and Sites that breached SLA. Maintenance updates applied counts updates applied in the month; updates still waiting are not counted. When there is nothing to count, a tile shows a grey word instead of a zero: None yet for the running month and None for a finished one (the outstanding tile always reads None). Typical time to patch reads N/A when no security update was applied, and Applied within SLA reads N/A when none was judged against an SLA, for example because every update was on a site without one. A count that may be incomplete reads "At least", but never "At least 0". On one site's report the two site-count tiles are left out, because the result block already says whether the SLA was met or breached.

Under All sites, the scoreboard has one row for each site: its name and address, the result, the month's day-by-day strip, Security (applied and late), Maintenance (changes and deployments) and Outstanding (the count, the age of the oldest, and whether any are overdue, not yet due or have no target). Breached sites come first, then those with the oldest outstanding item, then by name. "Not recorded" and "Insufficient data" are shown as grey words rather than figures. The key sits under the list. Select anywhere on a row to open that site's report for the same month and client. On a phone each row stacks into two columns with the strip across both. Anyone who can open Reports sees the Summary; nothing about access has changed. Under the headline figures, a Stack: line summarises known stack vulnerabilities across the sites in scope (see Stack vulnerabilities below).

The result block states the result in words with an icon, for example "SLA met in September 2026", "SLA breached in September 2026", "No SLA set" or "Insufficient data for September 2026". Under it, a short sentence says why: how many security updates were applied and whether any were late, what is still overdue, or why the month could not be judged. For the running month the sentence ends "The month is still running, so this result can change." A row of facts follows:

Security target, and Maintenance target when the report carries one.
Security updates, as "applied, late", or "None applied" when there were none. The late count is shown only when the site was judged against a target.
Outstanding: the count, the age of the oldest, and how many are overdue, or "not yet due" or "no target" for the oldest when none is. It reads "None" when nothing is outstanding.
Maintenance updates applied, shown as "At least" where change history began part-way through the month, and Deployments, shown as "At least" where release records began part-way through it. Maintenance updates and deployments read "None" when there were none; where the records are partial, a zero reads "None recorded", never "At least 0".
Drupal core, Modules and Days reporting.

The day-by-day strip, its dates and its key sit at the bottom of the block. An agency note, if there is one, appears as its own block below. The block is not split across printed pages. Everyone who can read a site report sees it; nothing about access has changed.

A report link in a site's release details opens that site's report for the month. If a site link is no longer available, for example because the site was removed or is outside the selected client, the page says so and offers Show the summary.

The current month is provisional and its figures can change. A finished month's view uses its newest issued version when one exists; otherwise it is calculated from available data. An unavailable client link is refused rather than silently showing the whole organisation.

Read the report

Review the result, site outcomes, updates applied, outstanding advisories, deployments, and trend. In particular:

Met: the site had a target and sufficient reporting evidence, with no breach in the period.
Breached: at least one day exceeded the patching target.
No SLA set: there was no target to judge.
Insufficient data: the evidence could not support a result.
Not recorded deployments: release evidence was unavailable; this is not zero deployments.
At least deployments: release evidence covers only part of the period.
Not recorded: inventory history was unavailable for maintenance or component changes.

Changes in is the deployment ledger. It replaces the five change tables that older reports show (Security updates applied, Deployments with version changes, Version updates, Modules added and Modules removed). Each site has one table with a group for every observed deployment, oldest first. The group header shows the observed time, Deployment n, a Security run or Maintenance badge, the number of changes and the advisories fixed. It adds Includes a version rollback. when a version went back, and a View release link on screen.

Within a deployment, rows list security changes first, then maintenance, then modules added, then modules removed, A to Z by project within each. The columns are:

Project and Version: the version before and after. An added module shows only its new version and a removed module only its old one.
Type: Security with the advisory and its risk level beneath it, or No advisory tracked; Maintenance; Added; or Removed.
Available: when the first release that made the project outdated was published, read from the release catalogue. Unknown when the catalogue has no date for it. For a security row the advisory itself is dated on its evidence row, not here.
Applied: the time Sentinel observed the change.
Time to apply: from Available to Applied, for example 16h, 5d 18h or 2w 3d.
SLA: for security changes Within SLA, After SLA or Not judged, or No advisory tracked when the security release has no advisory for your site. For maintenance changes, the result against your maintenance target, or No SLA when none is set. Added and removed modules are not judged.

When an update passed through more than one release, for example 1.2 to 1.5, the row has a Show n releases button on screen. It opens one line for each release with its version, release date and whether it was a security or maintenance release. A printed report shows these lines open. The time to apply counts from the first release.

The last group, Outside recorded deployments, lists changes that no observed release in the period accounts for. On screen, tick Security only to hide maintenance, added and removed rows, and any deployment left with no security rows. The tick box is never printed. A security row links its advisory to its entry in Outstanding at the end of the period, Fixes confirmed without an observed time or Ended without a counted patch when it has one, and otherwise to the advisory on drupal.org. With Security only on, a deployment's header says how many of its rows are hidden. Colour is never the only sign of a state: every state also has a label.

A security update counted as applied that no release record ties to a deployment is listed under Security updates applied outside the ledger, directly below the ledger. Outstanding at the end of the period, Fixes confirmed without an observed time and Ended without a counted patch stay under the ledger, in that order. Reports issued before the ledger fields existed keep their original tables, including Version updates and Maintenance updates. Anyone who can read a report sees the ledger. No role, permission or plan changes apply.

on a timeline is a picture of the month above Changes in . It is on screen only: it is never printed and is not in the PDF. It is being rolled out gradually, so it may not be visible in your account yet; nothing else about reports changes when it appears. Reports issued before the ledger fields existed have no timeline.

A line runs from the first to the last day of the month, with a tick each week.
A red circle is a day on which an advisory's SLA clock started: its publication, or the day the site was added to monitoring if that was later. A number shows when several share the day; the details say when a clock started later, for example after a fix was undone.
A blue square is a deployment. A filled square with a shield is a Security run; an outlined square with a wrench is Maintenance.
An amber diamond marks advisories still open at the end of the period. While the month is still running it sits at the time the report was made, not at the month end, and the bars of open advisories stop there too.
An outlined red circle at the start means advisories whose clock started before the month and that were still open when it began.
A bar runs from when a counted fix's clock started to the deployment that applied it. A thin green bar was within the target. A thicker red striped bar went past it. A thin grey bar had no SLA target to judge against. An advisory still open has a bar with a dashed edge to the end of the period, or to the time the report was made while the month is still running. Maintenance, rolled-back fixes and fixes without an observed time have no bar.
Hover over a marker, or move to it with the keyboard, to see its details. Select a marker to jump to its deployment in the ledger, to the advisory's row below the ledger, or to the advisory on drupal.org.
With more than twelve advisories and deployments, the labels become counts; use the ledger for the detail. Screen readers get the events as a list in date order.
The Summary shows one timeline for each site when fewer than six sites are in scope, and none otherwise.

Anyone who can read a report sees the timeline once it is switched on for your account. No role, permission or plan changes apply.

Applied, fix observed means the site reported a version fix supported by retained evidence. Observed is the first supported fix observation. Confirmed is when Sentinel confirmed the result. These times can differ; neither proves when a deployment finished. Available versions and linked release details help explain the fix.

Fixes confirmed without an observed time means a version fix was confirmed but its observation time is missing. It is shown separately and excluded from applied totals, within/outside SLA fix totals, and typical time to patch. Removed, not-applicable, rolled-back and legacy endings are also separate from applied fixes. Missing evidence does not mean a successful patch.

Fix markers identify observed fixes on the daily strip. A fixed issue does not erase a previous breach: the month can remain Breached even when its breached fixes are now applied.

Deployments are counted as described in What counts as a deployment below. Release coverage and inventory history are separate; check both before comparing months. Recalculated months and trends can change as evidence changes, while issued figures remain fixed.

The compliance calculation includes judged fixes and outstanding exposures already overdue. A fix observed after the month ends can still be outstanding in that month's report. Calendar boundaries use the organisation owner's time zone.

What counts as a deployment

In Sentinel, a deployment is a change your site reports in the version of Drupal core, a module or your own custom code, or a module or custom code added to or removed from the site. It usually means new code was released, but Sentinel records what the site reports and does not verify the release itself.

Sentinel does not connect to your hosting or build tools. It learns about deployments from the regular check-ins your site sends through the Sentinel Connector. When a check-in shows a different, known version of at least one component than the check-in before it, or a module or custom code added or removed, Sentinel counts one deployment.

Several components changed at the same time count as one deployment.
Moving back to an older version also counts. It is marked as a rollback when Sentinel can compare the versions; custom code and development versions are not marked.
Adding or removing a module or custom code without a version change counts as a deployment. Its rollback status is unknown, and its rows are not counted as version changes. Modules that appear or disappear only because the connector's reporting scope changed are not counted.
A version change where the old or new version is unknown is not counted. Unknown-version changes without a qualifying version change are shown as inventory activity.
A change only in how the same version is written, such as 8.x-1.5 to 1.5.0, is not counted.
The site's first check-in, check-ins with no changes, and changes entered by hand in Sentinel are not counted.

Because Sentinel only sees what your site reports, the date shown is when Sentinel first noticed the change, not when your deployment finished. Two deployments made between check-ins appear as one, or not at all if the second undoes the first. Sentinel cannot tell which environment or tool made the change.

If Sentinel's records for a site start partway through the month, for example because the site was connected mid-month, the report shows At least a number. If there are no records for the site, or they start only after the month ended, it shows Not recorded (Unknown on a site's Releases page): the count is unknown. Neither means there were no deployments. Zero means Sentinel observed no qualifying version changes in the month. It does not prove the site checked in throughout the month; check Days reporting for that. In the summary, when some sites have a count and others lack records for the whole month, the total shows At least.

Tickets in reports

Where ticket links are turned on for your organisation (see Ticket links), a site report shows the ticket for each finding. If you see no Ticket column, your organisation does not have ticket links yet, and the report is the same as before.

Ticket column. The security update rows and the stack vulnerability rows have a Ticket column. It shows the ticket number as a link that opens in a new tab. A ticket you pasted as a full address shows as View ticket, or as your label. Under the link, a second line gives the name of the ticket system, or the web address host for a pasted link. A finding with no ticket shows a dash.
As it stood at the end of the month. The report shows the ticket the finding had when the month ended. A link you add, replace or remove later does not change a report for an earlier month. If you edit a ticket system's link template later, the report still opens the address it was saved with. A finding that came back after being fixed starts with no ticket in the report, as it does on the site.
Ticket list. After the site sections, the Ticket list groups the findings in this report by ticket. Each row has the ticket (the same number in two ticket systems is two rows), the sites in this report that it covers, and how many findings. A finding counts once, and a No ticket row counts the rest. The list names only sites in the report you are reading. Its caption says that grouping does not confirm that the updates were deployed together. The Summary has no ticket list.
Nothing else changes. Tickets never change the result, the SLA figures, the counts or the deployment ledger. Printing, Download PDF and issued versions show the same Ticket column and list. Reports issued before ticket links existed show no tickets.

Anyone who can read a report sees its tickets. Linking and removing tickets still needs a Site manager or an Organisation admin, as described in Ticket links.

Stack vulnerabilities

A site report ends with a Stack vulnerabilities section. It lists known vulnerabilities (CVEs) that match the versions of the site's PHP, web server and database: PHP, Nginx, Apache, MySQL, MariaDB and PostgreSQL. Other products (LiteSpeed, Microsoft IIS, Caddy and SQLite) are listed but not checked yet. The wording is always "matches known vulnerabilities", never "is vulnerable": a match is made by version, and a vendor may have patched a problem without changing the version number.

Stack versions shows the version of each component at the end of the month, and whether it was reported by the site or declared in the site settings. Not shared means the site owner turned off Report platform versions for that month, and the component's open matches are left out. A product Sentinel does not match yet, such as LiteSpeed, Microsoft IIS, Caddy or SQLite, shows Not checked yet. A component with no version shows Not reported or Version unknown. Some managed or forked database builds, such as Amazon Aurora MySQL, Vitess or PlanetScale, TiDB, Percona Server and MariaDB Enterprise Server, use version numbers that do not follow the upstream releases, so Sentinel cannot match them. They also show Version unknown, never as clear of vulnerabilities.
Coverage tiles under the stack sentence in the report summary: Sites checked (for example "3 of 4", with "Full coverage" or "Partial coverage"), Open at month end (the open matches, or "None") and Not reported (sites whose web server and database were not shared, labelled "Platform sharing turned off"). Each tile states its meaning in words as well as colour. Sites on connectors older than 1.4.0 are not counted as not reported.
Open at the end of the period lists each match with its CVE, component, version, severity, Known exploited flag, the version that fixes it and when Sentinel first showed it. While Sentinel's Ubuntu and Debian checks are on, a match that Ubuntu or Debian says is not fixed in your build shows the vendor's fixed package build as the fix, when the version Sentinel recorded for that month includes the package build; otherwise the usual fixed version shows.
Resolved this month lists matches that ended in the month, how (for example upgraded to a fixed version, Fixed by the operating system vendor's update or Operating system vendor says not affected) and the date.
Acknowledged as not affecting the site lists matches your team marked as not affecting the site, with the reason, note, who and when. A decision from an earlier month that is still in force is included, with its original date.
Acknowledgements withdrawn or reopened this month appears only when there is one. It gives the date, why it ended and the result. Two reasons come from the Ubuntu and Debian checks: Operating system vendor now lists this as affected (the vendor says your build still needs a fix, or has none yet) and Operating system vendor checks switched off.

The figures are as they stood at the end of the month in the organisation owner's time zone, so a report made again later still shows that month as it was. Fixed in is the exception: it describes the vulnerability as known when the report is made, including the vendor's fixed build. Matches that are probably vendor fixes (low confidence) are never shown. The Summary has one Stack: line under the headline figures, counting the sites in scope with open matches, the open matches by severity and the acknowledged matches. The section is printed and is in the PDF. Reports issued before this section existed do not have it. Anyone who can read a report sees it; no role, permission or plan changes apply.

Print and download

Use Print to open the browser print dialog. The report is designed for a white A4 document in either dashboard theme. Every ledger row is printed, with the release lines open; a deployment that fits on a page is kept on one page, and the column headings repeat when the table runs over. The downloaded PDF has a bookmark for each block of the report: on a site report Verdict, Changes, Outstanding, Evidence (when there are evidence tables) and How this report is measured; an organisation report has a branch per site. Use Download PDF when offered. This requires an export permission and the enabled PDF service. Wait while the file is prepared; follow any reported failure and retry when appropriate.

A normal User can read and print an accessible report. Site managers and administrators normally also have PDF export permission. Always check the organisation, client, month, and version before sharing a file.

Issue, regenerate, and add notes

An administrator can issue a finished month or regenerate it from current evidence. Regeneration creates another version; it does not overwrite the earlier one. The running month cannot be issued.

An authorised site manager or administrator can add a note to the latest issued report. Saving a note creates a version with the same figures. Regeneration can update evidence and branding, while earlier versions remain in the archive. Report version details identify the preceding version and any reason. Older reports can show Recorded as applied when their stored rows have no observation evidence. Use a regeneration reason when needed to explain the new version.

Sentinel support can also regenerate an issued report for you, for example to correct a fault. The new version appears in Archive like any other version, and the earlier version stays. Its reason reads "Regenerated by Sentinel support" and no author is shown. The note carries over. Sentinel does not email this version automatically.

Open Archive to inspect issued versions and return to the required report. The Covers column names the site, or shows a summary for reports issued for a client or the whole organisation. Those earlier summary reports can still be opened, printed and downloaded. A stored version preserves its report figures even if a site or SLA changes later. Automatic issue is designed to run two days after month end where scheduled reporting is enabled, and issues one report per site plus the organisation report used for the monthly email; check Archive for the actual result.