Every release,
in the open.

Visual monitoring now ignores transient HTML noise (timestamps, ad slots, dynamic class hashes, etc.) instead of triggering a screenshot capture on every minor content drift. Fast-cadence monitors now wait for several consecutive content mismatches before enqueueing a screenshot, and once a screenshot is enqueued there is a cooldown window before the next one can fire. Customers running noisy sites (e-commerce, news, dashboards) will see far fewer false-positive captures and far less alert noise. Slow-cadence monitors (one-hour-plus intervals) still react to the first mismatch since each check is more significant. The threshold is configurable per monitor.

• ImprovedVisual monitoring now waits for several consecutive content drifts before queueing a screenshot capture, then sits in a cooldown window before the next one. Cuts false-positive captures on dynamic pages substantially, configurable per monitor.
• ImprovedReduced memory usage of one-shot screenshot captures used by the HTTP checker.

When an active or recently-resolved visual change incident is opened, the before/after/difference screenshots now stay viewable for at least 30 days. Previously, on monitors with frequent UI changes, the comparison images could be cleaned up the same day an incident closed (sometimes while the incident was still open) leaving the dashboard with placeholder boxes instead of the actual evidence. No customer action required. The deeper architectural fix that stores incident evidence completely separately from the rolling screenshot pool is planned for a future release.

• FixThe before, current, and difference images shown on a UI change incident now stay viewable while the incident is open and for 30 days after it closes. Previously, on monitors with frequent UI changes, those images could disappear within hours.

Two small fixes. First, the per-service status pages (e.g. visualsentinel.com/tools/status/playstation) no longer crash for mobile users whose browser auto-translates the page into another language. Now they render cleanly across translation modes. Second, when the visual monitor detects a UI change, it now only reopens a previously-resolved incident if the prior incident closed within the last hour (was 24 hours). Practical effect: a fresh UI change the next day opens a fresh incident with a fresh detection timestamp instead of re-attaching to yesterday's incident and showing yesterday's date on the alert.

• FixPer-service status pages (e.g. /tools/status/playstation) no longer crash on mobile browsers when the page is auto-translated from English into another language.
• FixWhen a visual change is detected, the system now only reopens a previously-resolved incident if it closed within the last hour. Was 24 hours. New changes the next day get a fresh incident with a fresh detection timestamp on the alert.

Restored visual capture reliability after a regression in the previous release. No customer action required.

• FixVisual captures are reliable again.

Tiny visual fix. The β beta badge next to the Content tab was rendering as a plain capital B because of an inherited CSS uppercase rule. Now it correctly shows the lowercase Greek beta character.

• FixThe β beta badge on the Content tab now renders as the intended lowercase Greek letter instead of a capital B.

Internal build reliability fix. Builds now complete in their normal time again. No customer-visible behavior change.

• FixInternal build reliability fix.

Internal startup cleanup hardened against an edge case that could halt it early. No customer-visible behavior change for monitoring.

• FixInternal startup cleanup is more resilient.

Added a small β badge next to the Content tab inside the single-monitor view. Content monitoring is the most volatile of the six layers (the underlying detection is hash-based and there is no restored-state notification yet), and we want customers to know it is still under active iteration before they wire alert rules around it. No change to any monitoring behavior.

• ImprovedA β (beta) badge now appears next to the Content tab inside individual monitor views, so customers can see at a glance that content monitoring is still under active iteration.

When a monitor recovers from a DOWN state, Discord and Slack alerts now include how long the monitor was offline (matching what email and WhatsApp already showed). Same shape of fix as the previous release's UI Restored duration improvement, applied to the DOWN to UP recovery path.

• FixDiscord back online alerts now include a "Was down for" field showing the downtime duration.
• FixSlack back online messages now include the downtime duration in parentheses.

When a UI Restored alert fires after a visual change has cleared, Discord and Slack now show how long the page was off baseline (matching what WhatsApp and email already showed). Server Recovery alerts in Slack also now include the offline duration and the previous issue label, matching the Discord embed.

• FixDiscord UI Restored alerts now include a "Was changed for" field showing the duration the page was off baseline.
• FixSlack UI Restored messages now include the change duration in parentheses.
• ImprovedSlack Server Recovery messages now include the offline duration and the previous issue label, matching Discord.

Additional network-layer protections for visual monitoring captures. Monitors of CDN-fronted, multi-host, and certificate-pinned sites continue to work unchanged. No customer action required.

• SecurityEnhanced security hardening for visual monitoring captures.

Cleaner error reporting in visual monitoring when a target site is extremely slow to render. Same screenshot budget, same outcome for slow sites, just a tidier alert trail. No customer-visible behavior change for monitors that complete normally.

• ImprovedCleaner error reporting when a visual monitor screenshot exceeds its 30-second budget. Underlying screenshot timeout behavior is unchanged.

Fixed an internal bug where the daily NPS Day-14 lifecycle email could not run. Other lifecycle emails (welcome, day-3, day-7, weekly digests, monthly product updates, milestone emails) were unaffected. NPS Day-14 emails resume on the next daily cycle. No customer action required.

• FixNPS Day-14 lifecycle email is delivering again.

Additional network-layer protections for HTTP and HTTPS monitor checks. Monitors of CDN-fronted, multi-host, and certificate-pinned sites continue to work unchanged. No customer action required.

• SecurityEnhanced security hardening for HTTP and HTTPS monitor checks.

Additional protections for the server monitoring agent install and report paths. No customer-visible behavior change. Existing agents continue to work unchanged.

• SecurityEnhanced security hardening for the server monitoring agent installer and report endpoints.

Two threads in one release. First, a new server alert type for the server monitoring agent: high load average. CPU% on its own can stay under your threshold even when a server is being hammered (a common pattern under fork-bombs, runaway processes, and heavy I/O wait, where cores look idle while work piles up). The new Load alert watches the 5-minute load average normalized against the server's CPU count and pages you when work is queueing faster than the box can process it. Defaults are calibrated against industry references (warn at 2x cores, critical at 4x cores) and every server's thresholds are tunable from the alert configuration drawer. The alert message includes the 1m, 5m, and 15m load averages plus the per-core saturation percentage so you know at a glance whether load is climbing or settling. Second, a stability pack for the visual-monitoring pipeline: warm browser pool re-enabled, post-deploy ramp-up made instant instead of half an hour, scheduler clock no longer reset on every worker boot, and full-size visual evidence preserved on the dashboard for the most recent four resolved incidents per monitor in addition to the open ones.

• NewNew server alert: High Load Average. Fires when work queueing per CPU core crosses your warn or critical ratio, even if individual-core CPU% never crosses the legacy threshold.
• NewPer-server tunable warn and critical ratios in the alert configuration drawer. Defaults of 2.0x and 4.0x cores match the industry consensus (Brendan Gregg, Netdata, Datadog system.load.norm.5).
• ImprovedServer status pill on the dashboard now flips to Degraded on sustained high load too, not just on CPU/Memory/Disk breaches.
• FixVisual monitoring browser pooling re-enabled. Previous-release stability issue resolved and pinned with regression tests; visual checks now reuse warm browsers across captures as designed.
• FixPost-deploy ramp-up for visual checks is now instant instead of taking up to an hour. Coverage is full immediately after a release without a thundering herd.
• FixBackground restarts no longer reset the next-check clock on healthy live monitors, so 5-minute uptime monitors keep their cadence across deploys.
• FixDashboard "Recent visual incidents" no longer loses the full-size capture, baseline, and diff images for the four most recent resolved incidents per monitor.
• FixServer status pill no longer resets on every background restart for monitors whose state was healthy before the restart.
• ImprovedVisual monitoring baselines now capture within seconds of becoming eligible. Whether you start a free trial, a paid trial, or upgrade to a paid plan, your existing monitors get their first baseline screenshot immediately instead of waiting up to a full cadence cycle.

A focused performance release for visual monitoring. Three changes compound: a warm browser pool that keeps browsers alive across checks instead of relaunching each time, an adaptive page-load wait that skips the slow wait after a monitor has had 5 clean checks in a row, and an expanded content-change filter that ignores common dynamic page noise so more checks exit on the fast path without launching a browser at all. The result is roughly 10x more monitors serviceable at the same compute cost.

• ImprovedVisual monitoring is dramatically faster per check. Stable monitors now skip heavy browser launches and page-load waits that are not needed.
• ImprovedSmarter content-change detection: more dynamic page noise (session IDs, cache-busters, generated class names, tracking tokens) is filtered before comparison, reducing false positives.
• ImprovedIdentical screenshots are now detected in milliseconds instead of going through the full pixel-by-pixel comparison.
• ImprovedVisual monitoring concurrency ceiling increased. More captures now run in parallel automatically.

A focused reliability release for visual monitoring. We found that some visual-enabled monitors were silently missing their scheduled comparison captures, meaning a real UI change could go undetected and (more importantly) a fix never got picked up as a restoration. This release rebuilds the scheduling layer to never reset a live monitor's clock, prunes accumulated stale state, and lifts the visual monitoring throughput ceiling by 2x to match the available headroom. On the incident side, restoration now fires correctly when a visual-only incident is still open but the monitor's uptime status has already flipped back to Operational, and posting a Postmortem update on an un-resolved incident now atomically marks it resolved (the Postmortem is conceptually one step beyond Resolved, so it shouldn't need a separate click).

• FixVisual monitors that went quiet after worker restarts now fire reliably again. Newly-added visual monitors register and start comparing on their configured cadence without gaps.
• FixWhen your site visually returns to the baseline, the open UI Changed incident now auto-resolves and you get the restoration notification, even when the monitor's uptime has already flipped back to Operational first.
• FixPosting a Postmortem update directly on an un-resolved incident now also marks the incident as resolved at that moment, so the public status page and your MTTR numbers reflect reality instead of a still-open incident with a postmortem written.
• ImprovedVisual worker throughput ceiling lifted from 12 to 24 concurrent captures per host (IO-bound, not CPU-bound). You keep visual monitoring keeping up as you add more visual-enabled monitors.

A small but visible fix to internal error noise. When a monitor is deleted while a check for it is mid-flight (the external HTTP + render can run for 30+ seconds), the final step that saves the check row would fail and raise an alert. The delete is the normal expected behaviour, so we now skip the write silently instead of treating it as an error.

• FixDeleting a monitor while one of its checks is mid-flight no longer surfaces an internal error. Check writes that fail because the monitor is gone are now silently dropped, as intended.

Two user-visible fixes and one visual overhaul. The auto-resolve toggle now actually holds the incident open when you switch it off (it was leaking through four other recovery paths we missed). The incident drawer now shows the full update timeline, matching the detail page. And the Past Incidents section on your public status page has been rebuilt to match the layout industry-standard status pages use, date headers grouping the incidents of each day, each incident's full update timeline flat-rendered inline, and the day's wall-clock time shown in your organization's timezone.

• FixAuto-resolve toggle actually works now. Flipping it off prevents every recovery path from closing the incident (previously four of them leaked).
• FixThe incident drawer on the Incidents list now shows the full update timeline (same as the detail page). Previously it only rendered an empty section because the underlying API never returned the updates.
• ImprovedPast Incidents on your public status page is redesigned to a date-grouped timeline matching the layout used by status.claude.com and similar sites. Each day lists its incidents with the full update log inline.
• ImprovedEvery automatic resolution (slow response recovered, SSL renewed, PageSpeed score improved, 1-hour stale cleanup, orphan cleanup) now leaves an explicit System entry in the incident timeline explaining why.