Troubleshoot health monitoring and notifications¶
Health Monitor is unavailable¶
Health Monitor requires Site Admin-level authority or higher. Confirm your role and site or client assignments. Cloud-service targets are limited to platform administrators.
A target is missing¶
Clear search and filters, select the expected client and site, and disable Problems only and Stale reports only. The grid returns at most 1,000 rows, so narrow the scope if the environment is large. If it is still absent, confirm that the source application registered the target and is reporting under the expected site, managed entity, target key, or device identifier.
A working target appears Offline¶
Offline is calculated from the heartbeat, not only the last reported status. Compare Last Report with the target's Offline After threshold and the current site-time or UTC display. Confirm clock synchronization, network connectivity, reporting interval, background process health, and the identity of the target being viewed. The fallback threshold is 180 seconds.
Last Seen Online or details are blank¶
The reporting source may not have supplied the relevant metadata, component details, or diagnostic fields. Blank data does not establish that the target was never online. Check the target key and device identifier, then inspect the source logs and most recent registration event.
Component state and overall status disagree¶
Compare observation times. A component snapshot may be older or newer than the target summary, and a single unhealthy dependency can drive the overall state while most components remain healthy. Refresh, confirm a new heartbeat, and inspect raw Selected Details and Events for the transition.
A health problem has no active alert¶
Health status and notifications are related but separate. Confirm that an enabled rule matches the target's site, target type, component type or key, and status. Then check debounce timing, exact statuses versus minimum severity, maintenance suppression, existing alert state, and site access. Active Alerts shows only unresolved alerts and at most 500 rows.
A rule will not save¶
Check the required name and, for Site scope, select at least one site. Timing values must be whole numbers; nonnumeric input produces a generic failure. Verify recipient rows were added to the grid before Save. Email and SMS format is not validated by the editor, so syntactically bad destinations may save and fail later during delivery.
I cannot edit a rule¶
Only platform administrators can edit global rules. For a site rule, a non-platform administrator must be assigned to every site included by that rule. Create a separate rule for your authorized scope or ask the rule owner to make the change.
Notifications are too frequent or duplicated¶
Review repeat minutes, debounce, target and component matching, and every enabled rule that can match the condition. Duplicate-looking notices may come from separate target and component alerts, overlapping rules, or different escalation recipients. Increase timing only after confirming the response requirement.
A recipient did not receive a notice¶
Open Deliveries and locate the attempt. For Failed or Skipped records, review the provider, channel, destination, and error. If no record exists, verify the alert, rule match, debounce, suppression, maintenance window, and recipient row. For Site Contacts, confirm the target site's contacts contain the chosen email or SMS channel.
Provider success does not prove human receipt. Check spam filtering, SMS carrier handling, destination ownership, and the external provider's message trace when the row is Sent.
A maintenance window did not suppress a notice¶
Confirm the window is enabled and that its start and end were entered in UTC in the correct order. Then confirm the notice occurred inside that interval and the matching rule has Suppress during maintenance enabled. A maintenance window does not suppress a rule that opted out, change target status, or erase an already recorded delivery.
An alert remains after acknowledgment or suppression¶
This is expected. Acknowledgment records ownership; one-hour suppression postpones notices. Neither action resolves the alert. Correct the underlying condition and verify a fresh recovery report. If the device recovered but the alert remains unresolved, compare target identity and timestamps, verify health-event processing, and escalate with the alert ID, target key, site, rule, and recovery evidence.
An alert disappeared but the problem remains¶
Recheck the current target and component states in Health Monitor. The alert may have resolved based on a new report, while the field symptom belongs to another component, another target, or a business workflow not represented by technical health. Capture target identity and timestamps before opening a support case.