Skip to content

Pulse v6.4.4-beta.1

Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 08 Sep 03:50
Immutable release. Only release title and notes can be modified.

✅ Release Asset Validation: PASSED

All release assets have been validated successfully!

Status: Ready for publication ✅
Validated: 2026-09-08 03:00:09 UTC
Workflow: Pulse Release Pipeline #411

Validation Summary

  • All required assets present ✓
  • Checksums verified ✓
  • Version strings correct ✓
  • Binary architectures validated ✓

Pulse v6.4.4-beta.1 Release Notes

This beta is a bounded alert-reliability checkpoint for Preview-channel
testers. It supersedes v6.4.3-rc.1, carries every change from the v6.4.2
packet that was tagged but never published, and adds integrated fixes for
notification finality, delivery-warning ordering, restart-safe alert state,
provider edge cases, notification-log confidentiality, discovery refreshes,
host telemetry, update reporting, reconnect behavior, and accessibility. It is
not an RC or stable release.

What's improved

  • Resolved alerts stay resolved - Retries cannot revive firing notifications after an incident resolves. Disabled destinations are cancelled instead of reported as delivered.
  • Delivery warnings stay current - Concurrent retries, dismissals and refreshes cannot let an older healthy snapshot hide a newer failure or restore a warning that was cleared.
  • Delivery failures are easier to diagnose - Failure status and reasons remain current after retries. Unavailable queue health is visible, with guidance to the affected notification settings.
  • Notification credentials stay private - Diagnostics mask webhook userinfo, Slack and Discord paths, Telegram tokens, encoded query credentials and ntfy URLs while retaining useful failure context.
  • Alert recovery follows observations - Missing storage or PBS samples do not clear incidents. Incident identity and history survive reloads and restarts until recovery is measured.
  • Provider alerts are more accurate - TrueNAS CORE 12 endpoints work, completed replication is recognised, informational events stay out of acknowledgement work, and NOTICE and critical events remain actionable.
  • PBS alerts survive restarts - Capacity, task, partial-metric and webhook behaviour remains tied to actual observations across restarts and recurring incidents.
  • Host telemetry is more dependable - Host and Docker CPU collectors use separate sampling baselines. Disk collection follows the agent mount namespace. Empty or pool-only Unraid layouts no longer invent parity warnings.
  • Update failures are clearer - Docker updates require independent success evidence. Oversized release metadata falls back to verified assets, and portable installer state retains correct ownership.
  • Identity and reconnects are safer - Same-name systems stay separate across Proxmox providers. Delayed browser startup offers a retry path, and infrastructure edits stay mounted during background polling.
  • Discovery repairs stay repaired - Suggestion backfill cannot overwrite a concurrent manual refresh with an older snapshot, lose a repaired URL or engine version, or resurrect a deleted record.
  • Navigation and settings are more accessible - The skip link comes first in keyboard order. Badges, landmarks, settings, Patrol, mobile navigation and compact controls have clearer focus and screen-reader behaviour.
  • GPT model compatibility is improved - GPT-5-family requests use the supported completion-token parameter and can learn the required parameter from bounded API responses.
  • Earlier preview improvements remain included - Windows agent delivery, faster large-estate scans, recoverable slow starts and accurate disk I/O totals remain included, alongside safer resource identity, agent operations and APIs.

Known issues

  • Open issue #1761 has a
    7 September report from stable v6.4.1 where both retained-failure actions
    returned HTTP 503 after CSRF validation. This candidate has integrated source
    repairs and tests around queue finality and warning reconciliation, but it has
    not been tested on that reporter's installation and is not claimed to fix the
    503. Do not delete notification_queue.db or alert files as a workaround. Keep
    the stable rollback pin and report sanitized action results.
  • A 7 September comment on #1812
    shows that a v6.4.1 user could see a retained-delivery warning but could not
    find its recovery controls or delivery-attempt details from the incident
    timeline. This candidate includes the Overview controls and Notifications
    activity view, but installed discoverability is not yet verified. The broader
    task-timeline and orchestration requests are not part of this checkpoint.
  • Open issue #1966 reports
    50-66 GB/day of Pulse process writes on one idle v6.4.1 LXC, plus repeated
    incident IDs sharing one occurrence start. This beta contains alert-lifecycle
    repairs but does not claim reduced aggregate write bytes, migration of old
    duplicates, or resolution on that installation. On flash-constrained test
    systems, monitor Pulse write volume and keep the stable rollback pin ready.
  • An advisory paired CI comparison measured UUID route-segment normalization at
    62.50 ns/op versus 51.64 ns/op, a 21.04% increase with no allocations. Local
    comparisons measured roughly 9-11%, and no end-user latency or throughput
    regression has been demonstrated. The integrated candidate-only benchmark
    passed, but that does not erase the paired result. This uncertainty is
    accepted for beta observation only and must be resolved or dispositioned
    again before RC.
  • Permanent SMTP authentication, configuration, or rejection errors can still
    consume the existing inner retry budget before queue handling, causing
    avoidable delay. This beta improves diagnosis and queue finality but does not
    include the separate main-line retry-classification repair.
  • Open issue #1913 reports an
    inaccessible GUI after changing a Docker deployment from v5.1.35 to stable
    v6.4.1. It does not yet distinguish direct access, published ports,
    reverse-proxy behavior, WebSocket routing, or exact running image identity.
    Keep the prior image pin available and include those details when reporting
    results.
  • Pulse Mobile does not require a companion mobile release. This server beta
    does not change Relay pairing, native push payload fields, approvals, or
    onboarding contracts. Ordinary off-LAN receipt, terminated-process replay,
    Doze, expiry, and failed-WAN cases are not claimed as qualified by this beta.
  • Historical notification rows are not rewritten or blindly replayed. The
    fixes govern new processing and operator retries.

Before you upgrade

  • This is an opt-in Preview-channel beta, not a stable release. Back up the
    Pulse data directory and keep the stable rollback pin available.
  • The v6.4.2 tag was never accompanied by a GitHub release and was not
    shipped. This beta carries that packet's administrator-boundary and security
    changes together with the published rc.1 and subsequent alert fixes. The
    preceding published stable release remains v6.4.1.
  • On an SSO-only deployment, map at least one trusted IdP group to the built-in
    admin role before upgrading so an intended administrator retains access.
  • For least-privilege rootless Docker or Podman monitoring, expose exactly one
    local collector-owned runtime socket. Ambiguous or invalid sockets may fall
    back to summary-only monitoring.
  • Windows Unified Agent binaries are not Authenticode-signed while SignPath
    remains unavailable and may show an Unknown Publisher warning. Verify
    downloads with published checksums and detached signatures.
  • The rollback target is stable v6.4.1. For systemd and Proxmox LXC, run
    sudo /bin/update --version v6.4.1. For Docker Compose, pin
    rcourtman/pulse:6.4.1 and recreate the container. For Helm, run
    helm upgrade --install pulse oci://ghcr.io/rcourtman/pulse-chart/pulse --version 6.4.1 with the values used by the current installation.

What to test

  • Exercise a threshold alert through firing, a missing observation, Pulse
    restart, genuine recovery, and recurrence. Confirm only the appropriate
    firing and recovery notifications arrive.
  • On a backed-up installation with retained delivery failures, try both Retry
    retained deliveries
    and Dismiss retained failures. Confirm each request
    succeeds without deleting queue or alert files, delivery history remains, and
    the warning reconciles promptly even while another health refresh is in flight.
    If either action fails, report the HTTP status and sanitized logs.
  • Retest PBS capacity and task transitions, TrueNAS replication and NOTICE
    events, host plus Docker CPU readings, and pool-only Unraid arrays.
  • Run a manual service-discovery refresh while availability suggestions are
    being backfilled. Confirm a repaired service keeps its type, name, URL, and
    engine version after restart, and inspect sanitized notification failures to
    confirm secrets are absent while the error remains actionable.
  • Upgrade a backed-up v6.4.1 installation, including Docker behind a reverse
    proxy, and verify direct GUI access, proxied access, WebSocket reconnect, and
    /api/version.
  • On high-request-rate installations, compare API latency and CPU with your
    previous pin and report any material change.

Install

For systemd and Proxmox LXC installs, use Settings → System → Updates or:

sudo /bin/update --version v6.4.4-beta.1

For Docker:

docker pull rcourtman/pulse:6.4.4-beta.1

For Docker Compose, update the image to rcourtman/pulse:6.4.4-beta.1 and recreate the container.

Pulse Pro and Relay customers should continue using the private download page and private runtime image for paid features.

Roll back

The rollback target is v6.4.1:

sudo /bin/update --version v6.4.1

For Docker Compose, set the Pulse image to the rollback target and recreate the container.