Services belong to a server and a workload
Service views place application and system-service checks beside the server that runs them. Discovery, templates, policies, and manual checks are available only when the agent and installation support them. That scope should be visible when a service is missing from inventory.
Investigate a warning
- Open the owning server and check agent freshness.
- Compare the service result with its expected template or policy.
- Inspect the last completed check and earlier status history.
- Use a manual check only for an authorized, registered asset.
Discovery is not a guarantee that every service has been found. The service health guide explains how to interpret coverage.
Define what a healthy service means
A service check should have a known target, expected state and collection method. A running systemd unit is useful evidence, but it may not prove that the application behind it is serving requests. Pair process or port state with relevant website and dependency checks when the workload requires it.
Discovery and coverage
Templates and discovery can reduce manual setup where the deployed agent supports them. Review the resulting inventory: services can be renamed, moved or intentionally stopped, and an undiscovered dependency can still fail. Assign alert recipients to the team that can investigate the host, and test one actual notification path before relying on it.
Can a check restart a failed service? Monitoring-only access does not authorize remote remediation. Escalation and operational actions must be separately enabled and scoped. See service-health guidance or compare managed operations.
