- localStorage preference has priority for persistence across reloads
- Server preference used only when no local preference exists (first visit)
- WebSocket broadcasts still sync theme changes across devices/tabs
- Maintains the cool real-time sync feature while fixing persistence issue
- localStorage preference now takes priority over server settings
- Server no longer overrides local theme choice on page reload
- Theme still syncs to server when toggled for cross-device support
- Fixes issue where dark mode would reset to light after refresh
The 100% threshold disabling feature was incorrectly implemented and doesn't
make logical sense - metrics can legitimately reach 100% (CPU, memory, storage)
and those are critical conditions that should trigger alerts.
The correct way to disable specific alerts is already implemented:
- Set threshold to 0 or negative to disable a metric type globally
- Use per-resource overrides to disable specific metrics for specific resources
- Example: Overrides[guest-id].Memory = {Trigger: 0} disables memory alerts for that guest
This removes the confusing behavior where 100% thresholds would disable alerts
instead of alerting on actual 100% usage conditions.
The dark mode state is now initialized immediately from localStorage when
the app loads, preventing the flash of light mode. Previously, dark mode
was always initialized as false and only set correctly after authentication
checks completed, causing it to briefly show light mode on every reload.
Also removed redundant theme application code throughout the authentication
flow since the theme is now correctly set on initialization.
Two critical issues fixed:
1. Storage threshold overrides were being loaded but never applied - the code
always used the default threshold instead of checking for overrides
2. Setting a threshold to 100% now properly disables alerts for that metric,
allowing users to suppress specific alerts they don't want
This fixes both the storage threshold persistence issue and the inability
to disable alerts by setting thresholds to 100%.
The issue was that PBS monitoring uses name-based IDs (pbs-<name>) while
the config system uses index-based IDs (pbs-0, pbs-1). When updating PBS
node configuration, the alert overrides were already being preserved but
the ID mismatch wasn't properly documented. Added explicit logging to
track PBS override preservation using the correct monitoring ID.
When detecting Proxmox cluster nodes, the Host field was being set to just the node name without a port. This caused validation to fail with "invalid Port number" error when qdevices were running.
Now cluster endpoints properly include the port (8006) in the Host field, allowing clusters with qdevices to be added successfully.
Updated the Physical Disks search to match the Storage Pools search field:
- Added container with white/gray background and border
- Added search icon on the left
- Matched padding, text size, and focus states
- Ensured consistent dark mode styling
The App.tsx had leftover debug code that would skip auth entirely and
return early, preventing the version info from ever being fetched.
This caused 'Version: loading...' to appear permanently in the footer.
- Limit alert checking to 50 guests per cycle to prevent blocking
- Remove unnecessary state broadcast when alerts are resolved
- Fix deadlock in GetActiveAlerts by releasing lock quickly
- Enable handling of 800+ mock guests with sub-10ms response times
This allows Pulse to handle large-scale deployments efficiently for testing and production use.
When a backup is accessible from multiple storages (e.g., BACKUP-VM and BACKUP-CT),
it was being displayed twice in the backup list. Added deduplication based on
VMID and timestamp to show each backup only once regardless of how many storages
can access it.
The alert acknowledgment endpoints were hanging because GetState() was called
synchronously to broadcast updates via WebSocket, which could take significant
time with many nodes/guests. This caused the HTTP response to timeout, showing
an error to users even though the alert was successfully acknowledged.
Fixed by:
- Sending HTTP response immediately after acknowledging the alert
- Moving WebSocket broadcast to a goroutine to avoid blocking
- Applied fix to all alert endpoints (acknowledge, unacknowledge, clear, bulk ops)
This resolves the issue where users saw 'Failed to acknowledge alert' errors
but the alert was actually acknowledged (disappeared on refresh).
The hysteresisThresholds object was incorrectly typed as Record<string, number> when it should contain objects with trigger and clear properties. This caused custom thresholds to not be saved properly, resulting in alerts still firing even when thresholds were increased.
Changed the type from Record<string, number> to Record<string, any> in all three places where threshold overrides are saved in ThresholdsTable.tsx.
When updating PBS nodes through the node configuration UI, alert thresholds
were being reset to defaults. This was because alert overrides are stored
separately from node configuration and weren't being preserved during node updates.
The fix ensures that when a node is updated, the alert configuration (including
any custom threshold overrides) is reloaded and preserved. This applies to both
PBS and PVE nodes to ensure consistent behavior.
- handle PBS node status endpoint permission errors gracefully (returns nil instead of error for 403s)
- add required cf and timeframe parameters to RRD endpoint calls
- properly handle nil nodeStatus returns in monitor.go
these API calls now fail silently as PBS API tokens often lack the required permissions for these endpoints, which is expected behavior
- Add retry logic with delays to detectPVECluster function to handle API permission propagation
- Periodically re-check standalone nodes to detect if they're actually part of a cluster
- Increase timeout from 3 to 5 seconds for cluster detection attempts
- Skip retries for definitively standalone nodes (501 not implemented errors)
This addresses the issue where adding a PVE cluster doesn't detect it properly on first attempt,
requiring deletion and re-adding to work correctly. The retry mechanism gives time for
API permissions to fully propagate in Proxmox.
Instead of making individual API calls for each guest's metadata,
load all metadata once at the Dashboard level and pass it down as props.
This reduces hundreds of HTTP requests to just one when dealing with
large deployments.
With 800 guests, this changes from 800 individual requests to 1 batch request.
The README previously claimed alerts for 'VMs go down' but currently only node down detection is implemented. Updated to accurately reflect that alerts are for nodes, not individual VMs/containers.
The cluster client was incorrectly marking nodes as unhealthy when encountering
VM-specific QEMU guest agent errors. This caused storage and backup operations
to fail with "no healthy nodes available" even though the nodes were actually
accessible.
Changes:
- Added broader detection for guest agent errors in executeWithFailover
- Updated recovery logic to ignore VM-specific errors when recovering nodes
- Guest agent errors no longer affect node health status
This fixes the issue where users with clusters would see storage and backup
operations fail after any VM without a guest agent was queried.
- Creates ~/.pulse marker file after successful install/update
- Addresses vhsdream's request in PR #7519
- Helps Community Scripts track that Pulse has been installed
- Improves compatibility between installation methods
- Use centralized detectServiceName() function instead of duplicate logic
- Automatically detect whether system uses 'pulse' or 'pulse-backend' service
- Improves compatibility between official and community installer scripts
- Reduces confusion when users mix installation methods
- Calculate memory as (Total - Available) instead of raw Used value
- Excludes buffer/cache memory that Linux can reclaim when needed
- Prevents false alerts from Linux cache usage
- Falls back to traditional calculation on older Proxmox versions
- VMs already use FreeMem from guest agent when available
- Memory usage will appear lower but more accurate (e.g., 56% instead of 84%)
- Users may need to adjust alert thresholds accordingly
- Add Available field to MemoryStatus struct to capture memory available for allocation
- Update node memory calculation to use Available memory when present
- This excludes non-reclaimable cache/buffers from used memory calculation
- Provides more accurate memory pressure indication, avoiding false alerts
- Falls back to traditional used memory if Available field is missing (older Proxmox versions)
When a threshold is set to 100%, it now effectively disables alerts for that metric.
This allows users to turn off specific alerts without disabling all alerts for a resource.
Also clears any existing alerts when threshold is changed to 100%.
- Changed logic to always query guest agent when available, not just when disk is 0
- This fixes issue where Proxmox returns incorrect non-zero values from cluster/resources
- Guest agent data is now preferred over cluster/resources data for all running VMs
- Improved logging to show when we're replacing cluster data with guest agent data
This should resolve the issue reported by FaboulousSan where VMs were showing
host disk space instead of actual VM disk usage.
- Add comprehensive filtering for network filesystems (NFS, CIFS, SMB, FUSE, 9p)
- Skip Docker volumes, snap mounts, and other special mountpoints
- Add detailed logging to track which filesystems are included/excluded
- Add sanity check to detect when reported disk is way larger than allocated
- Improve logging with GB values and more context for debugging
This should prevent Pulse from accidentally including host disk space or
network shares when calculating VM disk usage. Users can use the existing
diagnostics system in the UI to troubleshoot VM disk issues.
The disk monitoring backend was working but frontend wasn't updating because the WebSocket store was missing the handler for physicalDisks data. Also added physicalDisks count to broadcast logging for better debugging.
- Added DiskHealthSummary widget to dashboard showing:
- Total disk health status overview
- Healthy/failing/low-life disk counts
- Average SSD life remaining with visual bar
- Distribution of disks across nodes
- Added disk count badges to node selector in storage tab
- Shows disk counts next to storage pools count per node
- Webhook notifications automatically trigger for disk alerts via existing system
- Dashboard widget highlights issues with color-coded status indicators
- Added disk polling to monitoring cycle using Proxmox API
- Created CheckDiskHealth() alert manager for failing drives and low SSD life
- Added PhysicalDisk model to state with proper serialization
- Implemented DiskList component with health indicators and SSD wearout bars
- Added Physical Disks tab to Storage page with toggle between pools and disks
- Added ZFS health badges to storage cards for degraded/failed pools
- Alerts trigger for health != PASSED and SSD wearout < 10%
- Frontend displays disk model, type, temperature, and usage information
- Add API validation for cluster nodes to filter out qdevice VMs
- Only include nodes with working Proxmox APIs in cluster endpoints
- Prevent connection failures when cluster has non-Proxmox participants
- Add detailed logging for cluster node validation process
This resolves issues where Proxmox clusters using corosync qdevice
(external quorum device) would fail to connect because Pulse tried
to connect to the qdevice VM which has no Proxmox API.
- Add client-side URL validation with instant feedback
- Show validation errors inline below URL input fields
- Prevent saving when URLs have validation errors
- Improve error message extraction in API client
- Handle incomplete URLs like 'https://emby.' gracefully
- Backend already had validation, now frontend shows it properly
- Add more specific error messages when metadata save fails
- Better handling of permission and disk space errors
- This should help diagnose why guest URLs fail to save in some cases
- The atomic write operation was already in place but errors weren't clear
- Skip auth check entirely in App.tsx for development
- Add .env.dev file with DISABLE_AUTH=true and PULSE_MOCK_MODE=true
- Update hot-dev.sh to load .env.dev environment variables
- This ensures the app loads immediately without auth issues
- WebSocket and API now work without authentication in dev mode
Pulse Monitor