- Add debug logging to guest agent filesystem API responses
- Better handle Windows drive mountpoints (C:\, D:\, etc.)
- Improve empty filesystem list detection and logging
- Add specific handling for Windows filesystems that may report differently
This should help diagnose why some VMs with guest agents installed still show 0% or missing disk usage, particularly on Windows systems.
- Add comprehensive disk detection diagnostics to /api/diagnostics
- Shows which nodes return disks and which don't
- Provides specific error messages and API responses
- Includes targeted recommendations based on failure type
- Helps users provide better debugging info when reporting issues
- Add specific warning for permission errors (401/403)
- Add info message for nodes without disk monitoring support
- Elevate error logging from debug to warn level for visibility
- Helps users understand why disks might not appear for certain nodes
Debug code was accidentally left in v4.15.0-rc.3 that skipped authentication
entirely, preventing the login screen from appearing. This affected Docker
deployments where authentication was expected.
- Removed early return that bypassed auth checks
- Restored proper isLoading initial state
- Removed WebSocket early initialization
- Cleaned up debug console.log statements
- Increase WebSocket buffer sizes from 64KB to 4MB to handle large mock data
- Add robust reconnection logic with exponential backoff
- Implement heartbeat mechanism to detect stale connections faster
- Add manual reconnect button in UI when connection fails
- Fix unused variable warnings in monitor code
- Add debug logging to trace WebSocket state initialization
This resolves the issue where the frontend would hang after code changes
during hot-reload, especially when using mock mode with many nodes.
- Storage polling now preserves existing data when nodes are temporarily offline
- Backup polling preserves existing backups for unpolled nodes
- Prevents storage and backups from disappearing when nodes have connectivity issues
- Similar to the physical disk preservation fix
- Modified install.sh to avoid recursive chown on /etc/pulse during reinstalls
- This prevents custom thresholds in alerts.json from being lost during updates
- Only changes directory ownership, not existing file permissions
- Explicitly preserves permissions on critical config files
When a node is temporarily offline or has connectivity issues, preserve its last known physical disk data instead of removing it from the table. This prevents nodes from disappearing from the Physical Disks table when they have transient connection problems.
- Added 'pbs' type to Override interfaces in both Alerts.tsx and ThresholdsTable.tsx
- Fixed createEffect in Alerts.tsx to properly handle PBS server overrides
- Prevented memos from recomputing during editing to avoid input focus loss
- PBS threshold values now persist correctly when saved
- VMs/Containers default to 10 seconds
- Nodes default to 15 seconds
- Storage defaults to 30 seconds
- PBS servers default to 30 seconds
This allows more appropriate delays for different resource types instead of a single global delay that doesn't fit all use cases. Storage and PBS can have longer delays since they're less critical and more prone to transient spikes during operations.
The collapsible chevron icon was confusing users who didn't realize they needed to expand the section to see the alert delay and threshold settings. Now the global defaults are always visible.
- 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)
Pulse Monitor