v3.0.0

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.