Sentinel

Fixed

• The status report's greeting could hide urgent problems. When Statamic itself was up to date, the email opened with "the latest version" and never mentioned vulnerabilities, an end-of-life platform or a licence problem elsewhere. Those now follow the greeting, each named ("A security update is available for Laravel. PHP 8.1 has reached end of life."), and a Statamic update that includes a security fix says so. A Statamic patch release that isn't a security fix is called one ("1 patch version behind, not urgent").
• Turning off activity tracking kept showing, and keeping, the activity already recorded. With SENTINEL_TRACK_ACTIVITY=false the Users tab now drops its Status column and the stored activity is deleted. Activity older than 30 days also stops showing on a quiet site, rather than waiting for the next user to be recorded.
• Private packages were compared with public packages of the same name. A package installed from a path or VCS repository, or an npm scope served from a private registry, was looked up on Packagist, npm and the Statamic marketplace by name, so whoever owned that name publicly decided the "latest version" Sentinel showed, and could flag it as a vendor security update. These packages are now recognised and listed as not checked. A new private_packages config setting covers Private Packagist, Satis and private npm registries, and keeps those names out of the vulnerability lookup too.
• The utility and every report, schedule, note, preview and freeze action failed on sites that store users in a database. They checked for a super admin on the login guard's user, which on those sites is the app's own user model rather than a Statamic user, so each returned an error for everyone. If that model had an isSuper query scope, the check passed for any Control Panel user instead. Every check now goes through Statamic's user, and users who are super admins through a role now count as one, matching Statamic.
• A full disk could wipe Sentinel's saved data. When the server ran out of space mid-save, the half-written file replaced the old one (or the old one was deleted), and the save still reported success: history, the sent log, notes, schedules or a scheduled freeze could vanish. A failed save now leaves the previous file in place and reports the error.
• One failed email could empty the sent log. A mail server error containing non-UTF-8 text made the log unwritable, and it was saved as an empty file. Such text is now stored with a replacement character.
• Cancel and Mark complete reported success when the update record couldn't be removed. The freeze then carried on (banner, heads-up email, activation). They now report the failure.
• Scan now and Refresh failed on hosts that restrict PHP's file access (open_basedir). Looking for npm settings in the server user's home folder raised an error there, so every scan started from the Control Panel failed. That check is now skipped when the folder can't be read, and any scan that does fail keeps the previous report and returns to the page instead of showing an error.
• An unreadable package-lock.json read as "not found", and the next update report said every open npm vulnerability was resolved. A lock file can be valid for npm but not for PHP's JSON decoder: a field copied from any installed package's manifest (such as an odd character in its licence), merge-conflict markers, or a byte-order mark. npm checks then switched off without warning. Now the check shows as failed, the report keeps the previous figures, and sentinel:scan exits with an error. Byte-order marks and deeply nested fields are now read normally. The same applies to composer.lock.
• On Statamic 6 the freeze banner didn't appear on large pages. Statamic 6 puts the whole page into one attribute of its Control Panel shell, and on pages over about 1 MB (large entries, or Sentinel's own report with a long history) the check for that shell gave up, so editors opening such a page saw no update banner. The check no longer depends on page size.
• The update-scheduled email could name the wrong website. With Statamic's default site URL (/), the site name in the email came from the address of whichever Control Panel request happened to send it. Someone browsing through another address (or deliberately faking one) could have that address appear in the email to your client. Emails now always use the site's configured address (APP_URL).
• Email previews are sandboxed. Previews, including stored copies of sent emails, load inside the Control Panel, so a fault in an email template could in principle have run script there. They now load in a sandbox where no script runs, whether opened in the preview window or directly. Nothing exploitable was found; this is a safeguard.
• On Statamic 6 the freeze banner only changed when the page was reloaded. Statamic 6 moves between Control Panel pages without reloading, so editors who already had it open never saw the amber "update in progress" banner when the freeze started, or the green one when it finished. The banner now updates as they move between pages, and turns amber at the start time even if they stay on one page. It never reloads the page or polls in the background, so unsaved edits are safe and idle sessions still time out as before.
• A bad answer from the vulnerability database could hide or downgrade issues. A response that wasn't a real answer (for example a network page in its place) read as "no vulnerabilities", a cut-off advisory was stored as "unknown severity, no fix" until the advisory next changed, and a very long result was counted only up to its first page. These now count as a failed check, or are fetched again on the next scan.
• A damaged schedule file could stop every artisan command. Sentinel registers its scheduled tasks while the console starts up, and an unexpected value in its saved schedule threw an error there, which stopped schedule:run, queue workers and migrations along with it. Bad values are now ignored, and nothing Sentinel registers can stop the console.
• A crash mid-task could pause Sentinel's scheduled tasks for a day. If schedule:run was killed while one was running (a deploy or server restart), Laravel's default overlap lock kept the task from running again for 24 hours. Freeze checks now recover after 10 minutes, scans and status reports after 2 hours.
• A Packagist or npm outage looked like everything was up to date. If a package registry was down or rate-limiting during a scan, Sentinel reported "0 updates available", the status email said "Up to date" (and could claim Statamic was on the latest version), and the update history recorded a false drop. Now the check shows as failed in the Control Panel and the email, the history keeps the previous figures, and sentinel:scan exits with an error. Packages that aren't on the public registry still don't count as a failure.
• The update report could repeat an old report. A scan where only package versions changed (for example updates within the same major version), or where one vulnerable package was swapped for another, left every total the same, so it wasn't recorded and the next update report described the previous changes instead. Those scans are now recorded.
• Content Freeze emails were reported as sent when they'd only been queued. On sites that send mail through a queue worker, the Notify tab and Mark complete said the email had been sent when it was still waiting for the worker. They now say "queued" there. The Notify tab also says the amber banner appears at the start time, since the blue planned-work banner already shows from the moment an update is scheduled.
• A damaged data file was silently replaced. If one of Sentinel's saved files (history, sent log, notes, user activity, freeze history) couldn't be read, it was treated as empty and the next save overwrote it with just the newest entry. A damaged file is now kept beside it as <name>.corrupt-<date> (and logged) before a fresh one is started, and if a file can't be read at all, the save is skipped and the file left alone.
• Refresh could look like it did nothing. If the cache refused to store a new scan (for example a cache file created by another server user, or a cache with an item size limit such as DynamoDB on Laravel Vapor) but still held the previous one, Sentinel kept showing the old results. It now notices the saved copy is newer and shows that, and stops retrying a cache that won't take the scan.
• Content Freeze emails could go to clients more than once. The update-scheduled email was sent before Sentinel saved that it had been, so if the save failed (for example storage the scheduler couldn't write to) every minute's check sent it again; a slow mail server could also outlast the lock and let a second check send it. Mark complete had the same shape for the all-clear. Sentinel now records that it's sending before it sends, sends nothing if it can't, and a second click on Mark complete can't send a second all-clear.
• A failing mail server was retried on every Control Panel request. If the update-scheduled email couldn't be sent, every page view by any editor tried again. It now retries once a minute, and the Notify tab says the email hasn't gone yet.
• Two updates scheduled at the same moment could both report success, with one silently replacing the other. Scheduling (and deleting a past update) now waits its turn like every other update action.

Changed

• The status report's opening drops the "Hi," and reads "Your website is running Statamic 6.26.0. The latest version is 6.35.1." (or "…6.35.1, the latest version.").
• The status report labels each Statamic, Laravel and PHP update as Patch, Minor or Major, with "update available" beside it, instead of one "Update available" pill for everything. A routine patch no longer looks the same as a feature release, and a major gap is no longer worded differently from the rest. A security update overrides the tier and shows on its own.
• The Statamic row in the status and update reports shows the Statamic icon, taken from the site's installed Statamic and embedded in the email, so nothing is loaded from elsewhere when it's opened.
• Fixed vulnerabilities show as security updates in the update report's package lists. Any package update that fixed a vulnerability, including one pulled in by another package, is marked "(security update)" with the versions it moved between, instead of being repeated in a separate resolved list. The Vulnerabilities section now lists only new and still-open issues, and doesn't appear when there are none.
• The developer link now carries UTM parameters, including the site's domain, so D3 Creative, or an agency using SENTINEL_DEV_URL, can see which visits came from Sentinel. Nothing is sent unless someone clicks, and UTM values already on the configured URL are kept.
• Setting only SENTINEL_DEV_NAME no longer keeps D3 Creative's link and support email. A white-label name now stands alone; set SENTINEL_DEV_URL and SENTINEL_DEV_EMAIL for a link and the "Need help with your website?" button.
• Scans give up faster on a service that's down. Each request now waits at most 4 seconds to connect, and once a service has refused a connection during a scan, Sentinel doesn't wait on it again. With every service unreachable, a scan that took about 40 seconds now takes about 12. Sentinel also no longer follows redirects from the services it checks (none of them use them). If a scan is cut off by a server time limit, Scan now works again straight away instead of after five minutes.
• Statamic marketplace checks run together. Sentinel looked up each outdated addon on the Statamic marketplace one after another; they now go out at once, and a marketplace that refuses connections is skipped for the rest of the scan. With statamic.com unreachable and seven addons to check, that part of a scan drops from about 35 seconds to a few.
• Faster vulnerability checks on large projects. Sentinel sends packages to the vulnerability database in batches of 500, and waited for each batch before sending the next. They now go together: about 1 second instead of 5 for a project with 3,000 npm packages.
• Scans can't run out of memory on an oversized response. Sentinel read every response whole, however large; a few big npm registry documents could exhaust PHP's memory and kill the scan. Responses over 10 MB are now skipped (the update shows as "Unchecked"), and large documents are released as soon as they've been read.
• Smaller queued report emails. A queued status report carried the full scan (every advisory and package) twice, though the email only shows totals, which could exceed a queue's size limit (beanstalkd's is 64 KB) on a site with many advisories. It now carries just what the email shows, once. Stored send errors are also kept short, so one that quoted the whole message no longer bloats the Sent list.
• A lighter dashboard. Each time the dashboard or the Sentinel page loaded, Sentinel re-read composer.lock (twice) and all of package-lock.json to check whether anything had been updated since the last scan. It now skips that when neither file has changed since the scan.
• Scan history is capped at 500 entries as well as a year, and a failed Statamic licence check no longer adds an entry of its own. Users without super admin access no longer load the history, sent emails and schedules behind the scenes, since they can't see those tabs.
• The Users tab lists Control Panel users only. It listed every user on the site, front-end members included, and looked each one up on every load, which got slow on membership sites. On sites with more than 500 users it now lists the Control Panel users active in the last 30 days, plus you.
• A much lighter Sentinel page. Every delete button and note editor carried its own copy of the same script, and the History tab listed a whole year of changes. Those now share one script, and History shows the 50 most recent changes (the reports still use them all). On a site with a year of daily changes and 100 vulnerable packages, the page drops from about 2.5 MB to 0.7 MB.
• Fewer background processes. The two every-minute Content Freeze checks used to start a full artisan process each, every minute, even with no update scheduled. They now only run when a freeze is actually due to change.
• The Statamic licence key was visible to Sentinel users who aren't super admins. When the licence needed renewing, the "View renewal date" link (whose address contains the licence key) showed to anyone with Sentinel access. It now shows only to super admins and users who can open Statamic's own Licensing utility, which is where Statamic shows the key.
• Opening a report preview could start a full scan. Before the first scan, the preview links ran one, bypassing the limits on Scan now (and a link on another site could open them for a signed-in super admin). Previews now only show the last scan, or ask you to run one first.
• A malformed link could break the dashboard or the Notify preview. Adding [] to the Scan now or preview parameters in the address bar caused a server error. They're now ignored.

Removed

• Support for Statamic 3.3 and 4.x, PHP 8.0 and 8.1, and Laravel 8 and 9. Sentinel now needs Statamic 5 or 6 on PHP 8.2 or later. Statamic 3 and 4 no longer get security fixes: none of the 2026 Statamic security advisories has a fix on either, so a site on them is exposed whatever else it runs. PHP 8.1 lost php.net security support at the end of 2025. Sites on those versions stay on Sentinel 2.x (Composer won't offer them 3.0), which keeps working but gets no further releases.