rcourtman
880498df97
Scheduled reports could appear successful when email was unconfigured, and a temporary delivery failure had no durable retry or clear recovery path. Reports now checks email configuration, records running/saved/accepted/failed/unconfirmed outcomes, and exposes actionable errors and Run/Retry controls at desktop and mobile widths. Temporary mail failures receive at most three attempts with one- and five-minute delays. Retries survive restart and preserve resource-report windows. Lost completed-message acknowledgements and interrupted email runs remain unconfirmed until a deliberate retry, preventing automatic duplicate sends. Edits, disablement and deletion cancel pending retries. Every attempt rechecks the existing entitlement. This implements the scheduled-report delivery slice of L6. Pricing, feature gates, retention limits and existing customer entitlements are unchanged. SMTP acceptance is distinguished from inbox receipt. The schedule editor loads when creating or editing a schedule, with a visible loading state and initial keyboard focus. The reporting screen stays within its existing bundle budget without raising limits. Validation: - Full configuration and notifications Go suites, reporting API race tests. - 301 targeted frontend and architecture tests, TypeScript, full frontend lint and production frontend/private-runtime builds. - Existing bundle-size, total JS/CSS and preload checks passed. ReportingPanel is 10.94 kB gzip against its 11.63 kB limit. - Playwright on `/settings/support/reporting` and `/alerts/notifications` at 1440, 820 and 390 pixels: configuration failure, disabled draft, real CSV attachment, disk PDF, persisted retry across a process restart, permanent rejection, uncertain acknowledgement, deliberate retry and delete/disable recovery. - Controlled-response browser matrix for running, loading/error, polling, keyboard focus, details and responsive layouts. Final pixels reviewed separately from delivery assertions. - Release-control status, ownership, contract, completion and browser guards. Browser delivery uses synthetic infrastructure, a disposable signed Pro grant and local SMTP only. This source change does not publish a release or alter customer installations.
Pulse documentation
Start here for installation, platform setup, security, operations, and Pulse Intelligence. Commands, configuration keys, image names, API fields, and product identifiers remain untranslated in localized guides.
Need help with a failure? Read the safe reporting guidance before sharing evidence. A second reproduction or diagnostics export is not required; keep the original evidence if another attempt could interrupt workloads or send duplicate notifications. GitHub reports and attachments are public: review them locally and keep credentials and private details out.
Start here
- Install Pulse — signed Proxmox/Linux installation, Docker, Docker Compose, Kubernetes, and first-run setup.
- Production deployment and security — least-privilege Proxmox setup, root-agent boundaries, discovery, supply-chain verification, plan limits, scale evidence, and a rollout checklist.
- Upgrade from Pulse v5 — migration prerequisites, rollback, agent continuity, and post-upgrade checks.
- Releases and update channels: choosing Stable or Preview, beta and RC expectations, and how releases are tested and promoted.
- Configure Pulse — authentication, notifications, discovery, retention, and system settings.
- Deployment models — data locations, lifecycle, and differences between supported deployment paths.
- Troubleshooting and FAQ — common failures, diagnostics, and operator questions.
Localized getting started guides: Deutsch · Español
Platforms and agents
- Proxmox Backup Server
- Proxmox Mail Gateway
- Docker and Podman
- Kubernetes and Helm
- TrueNAS SCALE and CORE
- Unified Agent
- Agent security
- VM disk monitoring
- ZFS monitoring
- Temperature monitoring
VMware vSphere support is early access. Current builds expose dedicated vSphere inventory and recovery context, but operators should validate the integration against their own vCenter before production use.
Monitoring and operations
- Metrics history
- Recovery data
- Webhooks
- Automatic updates
- Centralized agent management (Pro)
- Operational trust model
- Current product screenshots
Pulse Intelligence
- Assistant, Patrol, and external-agent overview
- Patrol modes and safety
- Assistant safety model
- External agent HTTP and MCP substrate
Patrol watch-only analysis is available on Community with a local model or the operator's own provider. Investigation and governed fixes require the relevant Pulse Pro capabilities.
Security, privacy, and access
- Production deployment and security
- Security review scope
- Authentication and credential storage review packet
- Security guide
- Privacy and telemetry disclosure
- OIDC and SSO
- Proxy authentication
- Role-based access control (Pro)
- Audit logging (Pro)
- Reverse proxy configuration
- Code-signing policy
Plans and managed access
- Community, Relay, and Pro capabilities
- Relay and Pulse Mobile handoff
- Multi-tenant organizations (Enterprise/custom)
- Provider-hosted MSP operations (request-assisted)
Pulse Cloud is not generally available. Ordinary self-hosted Pulse remains the primary installation path; MSP and Enterprise access are explicit commercial paths rather than defaults in self-hosted setup.
Development and reference
Detailed design notes and dated migration specifications may remain in this directory for maintainers, but they are not operator setup guides unless they are linked from the sections above.
Previous versions and migrations
- Upgrade from v4 to v5
- Retired unified-navigation migration — historical context only; current Pulse uses platform-shaped navigation.
- Move a Pulse installation
Found a bug? Use the issue forms. For setup questions, use GitHub Discussions.