Monitoring
Endpoint health and connectivity history
What the agent records on a rolling basis, how to read it, and what the platform does not do with it.
Last updated
The agent reports health and internet reachability on a rolling interval, building a historical record rather than a point-in-time snapshot. This distinction is the whole value of the feature. A snapshot tells you the disk is at 80 per cent; the history tells you it was at 40 per cent three weeks ago, which is the version of the fact that lets you act before anything breaks.
Internet reachability history is recorded separately from general health, and reading the two together is more informative than either alone. An endpoint reporting healthy internals with intermittent reachability is a network story. One reporting degraded internals with clean reachability is a machine story. Teams that only look at one of the two regularly misattribute the first kind as the second and send a technician to the wrong problem.
History is where trend arguments come from. When you need to tell a client that a site needs attention, "these fifteen machines have shown degrading connectivity over the last two months, here is the chart" is a materially different conversation from "the users say it feels slow". The first is a budget conversation; the second is a complaint.
It is important to be direct about the boundary here. AegisOne records this history and surfaces it. It does not evaluate it against thresholds, and it does not notify anyone when something crosses a line — there is no alerting or escalation engine in the product. Health history is a diagnostic and reporting asset, not a paging system.
If you need paging today, the practical approach is to poll the API from something that already does alerting for you and evaluate the thresholds there. That keeps your on-call routing, suppression and escalation in the tool your team already trusts, which is where most people would rather have it anyway.