Health Monitoring

Heartbeat & Metrics

Agents send a heartbeat every 60 seconds. Metrics are sampled on their own cadence, set by HealthMetricIntervalSeconds (default 60). Each heartbeat carries the latest sample below. Metrics feed the alert rule engine, the Data Explorer, and the Smart Reports generator.

From agent version 2.8.4.9:

• When the sample interval is shorter than a minute, the heartbeat also carries every sample taken since the last accepted heartbeat, so a 15-second interval stores 15-second points.
• The system information, security posture, network adapter and services blocks are sent when they change and at least every HeartbeatStaticResendMinutes (default 30). In between the server keeps the last one it received. Adapter rates and Wi-Fi signal quality are current whenever the adapter block is sent.
• Detections, inflections, samples and the capability report stay on the agent until a heartbeat that carries them is accepted. A failed heartbeat no longer loses them.

CPU

• System-wide utilization %, per-core utilization % (array), CPU model name
• Context switches/sec, interrupts/sec, current frequency (MHz)

Memory

• Total, used, available, usage % — physical RAM
• Committed bytes, page file total & in-use, non-paged pool, system cache

Disk I/O

• Read bytes/sec, write bytes/sec, queue length, disk busy %
• Per-drive: letter, label, file system, total/used/free GB, usage %

Network

• Aggregate receive/send bytes/sec, cumulative totals, active TCP connections (v4 & v6)
• Per-adapter breakdown: name, MAC, IP addresses, DNS servers, link speed (Mbps), adapter type, receive/send rates

System Information

• OS edition, build number, feature update version (e.g. 23H2), last boot time, uptime (seconds)
• System manufacturer, model, BIOS version, total installed RAM
• Time zone, domain, domain-joined status, pending reboot indicator
• From agent version 2.8.4.9: the reasons for a pending reboot, the time sync source, the time of the last installed update, the count of pending updates from the last patch scan (when patch scanning is on), and how long the last boot took

Uptime and Connectivity (agent version 2.8.4.9 and later)

• Uptime in seconds and the clock offset from the time source, on every sample. The offset is read every HardwareSlowIntervalMinutes (default 10): from w32tm on Windows, from chronyc on Linux. A Linux host using systemd-timesyncd reports the source and no offset.
• How long resolving the ET Ducky API host name took, and the round trip to the default gateway, on every sample. On Linux the gateway is measured only when the agent's group is allowed unprivileged ICMP (net.ipv4.ping_group_range); otherwise the field is empty.

Hardware Health

• CPU temperature and voltage, battery charge and health, and the system thermal state, on every sample (Windows; values the hardware does not expose stay empty)
• From agent version 2.8.4.9, read every HardwareSlowIntervalMinutes and attached to every sample in between (Windows): a list of physical disks with model, bus and media type, temperature, wear, read and write errors, power-on hours, health status and the drive's failure prediction; Intel ME health; the date and code of the last bug check, WHEA hardware errors in the last 24 hours, and unclean shutdowns in the last 7 days from the System log. The worst disk's values also fill the single-disk fields older reports read.

Security Posture

• Antivirus: product name, real-time protection enabled/disabled, definitions up to date, definition age (days)
• Firewall: enabled/disabled
• Windows Update: last check timestamp, automatic updates enabled
• Encryption: BitLocker protection status on the system drive
• UAC: enabled/disabled, Secure Boot: enabled/disabled

From agent version 2.8.4.9 the posture is read at most every PostureCacheSeconds (default 600) and again at once when Security Center reports a change or a network address changes. A probe that worked before and fails now is listed as a posture probe failure instead of being shown as the last good value.

User Sessions

• Currently logged-on interactive user(s), session type (Console / RDP)

Event Log Summary (optional, configurable)

• Error and warning counts from the Application and System logs over the configured lookback window (default 1 hour)
• Most recent critical error source and timestamp

Anomaly-Triggered Diagnostics

The agent runs an inflection detector that compares each metric sample to the one before it. From agent version 2.8.4.9 it runs on every sample, at the sample interval; older agents ran it once per heartbeat. When a significant change is detected, the agent sends the buffered ETW events from 30 seconds before to 5 seconds after the change with the next heartbeat, capturing the raw kernel events that were occurring when the anomaly happened. A critical inflection sends that heartbeat about 5 seconds after detection instead of waiting for the next minute.

Inflection points reported to the cloud include (defaults; the thresholds are agent settings):

• CPU spike (≥40 pp jump), CPU drop (≥50 pp), sustained high CPU (≥90% for 180 seconds), single-core saturation
• Memory freed or consumed ≥1024 MB, usage jump ≥25 pp, available memory below 500 MB for 120 seconds
• Disk queue spike (<2 → >15), disk queue above 5 for 180 seconds, disk utilisation from below 30% to above 90%, write throughput >5× and above 50 MB/s
• Network receive or send spike >10× and above 10 MB/s, TCP connection surge of 1000 or more
• Drive crossing 80% or 90% full, rapid fill of 5 pp or more between samples
• CPU temperature spike ≥15°C or reaching 95°C, rapid battery drain ≥10% between samples

The sustained conditions are measured in seconds from agent version 2.8.4.9, so they mean the same at every sample interval. Older agents counted heartbeats.

Inflection data is stored in the AgentHealthMetrics table and queryable in the Data Explorer via the Metric Inflections (JSON) column.

Server Health Endpoints (/health and /ready)

The ET Ducky server answers two plain-text health endpoints. On a self-hosted instance they are served at the instance's address; the container's own health check calls /health.

Endpoint	What it checks	Status code
/health	Nothing beyond the process answering. It is a liveness check.	200 while the server is running
/ready	Five checks: the database connection, the root database connection used for cross-organization work, a tenant-isolation round trip, that the configured storage paths are writable, and that background services are running on schedule.	200 when the result is Healthy or Degraded, 503 when it is Unhealthy

A background service that is late makes /ready report Degraded, never Unhealthy, so it still answers 200. The service that sends the keepalive on agent connections every 30 seconds is the only keepalive those connections get, so one missed sweep is enough: /ready reports Degraded and the server log records an error. While it is missing, each agent notices the silence after 90 seconds and reconnects. The root connection and tenant-isolation results are reused for 10 seconds, so frequent polling does not open a database connection on every request.

What a caller sees

A caller on the server itself or on a private network address, whose request carries no forwarding header, gets the overall status followed by one name: status line per check. Any other caller, including every request that passes through a reverse proxy that adds X-Forwarded-For, gets the overall status and counts only, for example Healthy: 5 checks, 0 not healthy. The details of a failing check are written to the server log, never to the response.

Rate limit

Both endpoints are limited to 120 requests a minute per client address (health-per-ip). A caller over the limit is answered 429 with Retry-After. See API Rate Limits.

Per-Host Timeline in the Desktop App

In the ET Ducky desktop app, open Fleet, an agent, then the Timeline tab. It shows on one time axis: CPU, memory and free disk space on drive C, and lanes for detections, metric inflections, patch jobs, configuration changes, alerts, tickets and the troubleshooting runs any member of your organization started on the agent.

• Pick the last hour, 24 hours, 7 days, 30 days or 90 days. Drag the handles on the strip under the chart to zoom, or drag between them to move the window. Zooming does not reload anything.
• Health over 7 days comes from the 5-minute rollup, so the most recent day may not be in it yet. Organizations without extended retention have no rollup rows, and the band then says "no samples".
• Detections, inflections and troubleshooting runs reach back as far as your plan's data retention, and 14 days without a paid retention plan; the tab says when the range is longer than that. It loads up to 5,000 detections and 5,000 inflections and says when it stopped there. Alerts are matched to the agent by server name.
• Click an item for its details. A detection opens its evidence on the Security tab, a patch job opens the Patches tab, a ticket opens Tickets, and a troubleshooting run offers to troubleshoot again. A run the server ended because it restarted or because the run made no progress for 35 minutes shows as closed, with its own colour.
• An agent with no heartbeat for 7 days shows "no health data in 7 days" in the health band. A source that does not load shows a warning and leaves its lane empty; the rest of the tab still loads.

Retention

Health metric rows follow the org's configured data retention tier (14 days free by default). See Data Retention for tier details.