Files
pulse/docs
rcourtman 54a9a6451b Link alert cards to their platform from incident metadata (#2564)
The alert card chose its platform page by resource type, then by
searching the message for "vmware". Provider incidents sit on canonical
`vm`, `storage`, `network` and `agent` types, so that only worked while
a summary happened to name the platform. #2559 added an
`incidentProvider === 'vmware'` check for vSphere alone. On main, other
platforms still fall through:

- **TrueNAS pool incidents** link to the Proxmox overview, and Alerts ›
Overview › More › Monitoring says "Proxmox remains the inventory owner".
- **Agent alerts** link to `/machines`. No such route exists, so the
link opens "Page not found: No route matched /machines".
- **TrueNAS metric alerts** (`truenas-pool`, `truenas-dataset`, …) fall
through to Proxmox the same way.

**What changes**
- The card reads the platform from an explicit `platformType`, then the
incident's `incidentProvider`, then the resource's `resourceSources`,
through the shared `resolvePlatformTypeFromSources`. A PBS incident that
Pulse raises itself (provider `pulse`) resolves by its `pbs` source.
- That platform maps to its page through
`PRIMARY_PLATFORM_NAV_SCOPE_IDS` and the `routing/resourceLinks.ts` path
builders, and the same canonical id goes to the Monitoring policy menu,
so the link and the named owner agree. Raw route strings in the card are
gone.
- The resource-type and message fallbacks remain only for alerts whose
metadata names no platform, now with `truenas-` types, and with agent
alerts sent to `/standalone/machines`.
- vSphere links no longer depend on the alarm wording at all. #2559
already made them right on main by the provider check; this replaces
that special case with the general resolver.

**Verification**
- `AlertOverviewAlertCard.system-scope.test.tsx`: a vSphere VM alarm
whose message lacks "VMware", a TrueNAS pool incident, a PBS incident
with provider `pulse`, and agent and TrueNAS metric alerts without
incident metadata. Each asserts the link and the platform passed to the
Monitoring menu. All five fail against main's card; against the card
from before #2559, the vSphere VM alarm linked to `/proxmox/overview`.
- Private mock stack at main `af4e6a493c`, 1440 and 390: a vCenter alarm
on the mock VM client-portal-01 (message "Virtual machine memory usage")
and an agent-host CPU alert, appended to the live websocket
`activeAlerts` with Playwright `routeWebSocket`, plus the mock's own
TrueNAS pool incident. Each link was followed to the vSphere overview,
TrueNAS overview and Machines, and each menu named VMware vSphere,
TrueNAS and Pulse agent. With main's card swapped back in under Vite,
the TrueNAS card went to Proxmox with Proxmox as owner and the agent
card hit Page not found.
- Receipt: `frontend-modern/browser-verification/977a32825e65be8f.json`.
2026-10-06 12:15:15 +01:00
..
2026-10-05 21:53:41 +01:00
2026-10-05 21:53:41 +01:00
2026-10-05 21:53:41 +01:00

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.

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

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

Pulse Intelligence

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

Plans and managed access

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

Found a bug? Use the issue forms. For setup questions, use GitHub Discussions.