Elastic Fleet Agent Offline or Unhealthy After Reboot: Causes, Diagnostics, and Fixes

Elastic's own tracker does not point to one universal root cause for this symptom, and you should be skeptical of any writeup that claims otherwise. The realistic set of causes, in the order they are worth ruling out:

• Fleet Server itself is unhealthy, not the endpoint agent. Every enrolled agent's status depends on Fleet Server successfully receiving and forwarding checkins to Elasticsearch. If Fleet Server's own host rebooted and its agent came up before Elasticsearch or the network path to it was ready, every agent it serves can show offline even though those endpoints are fine. This is the first thing to check, not the last.
• Network re-initialization races with agent startup. On Linux hosts using systemd, the elastic-agent unit can start before DNS resolution and outbound routing are actually usable, particularly on cloud instances or VMs where network interfaces come up asynchronously during boot. The agent tries its first checkin, fails, and depending on version, does not always retry aggressively enough to self-correct quickly. The GitHub issue's own description of "agent seen as running on Host VM" while Fleet reports it offline is consistent with this: the process is alive, but its checkin path was broken at the moment it mattered.
• Stale local agent state. Agents keep local state (agent ID, enrollment token reference, action queue) on disk. An unclean shutdown, a cloned VM image that carries over another host's agent state, or a corrupted state file after a hard reboot can leave the agent unable to reconcile with Fleet even after connectivity is restored.
• A version-specific status-reporting bug. The GitHub issue tracked here (opened against Elastic Agent 8.7.0 BC5 running as Fleet Server on SLES 15) was closed against a linked fix, meaning at least one real, patched bug in this exact symptom existed in that version line. If you are running an older or affected build, the fix may simply be an upgrade.
• The standard fix does not always work, and that is itself diagnostic. In the Discuss thread, a maintainer's suggested restart (systemctl restart elastic-agent) did not resolve the reporter's issue after repeated attempts, and the thread closed without a confirmed root cause. Do not assume a restart is a fix; treat it as one data point in a larger diagnostic pass.

Work through these in sequence rather than jumping straight to a fix. Skipping the first step is the most common reason people spend an hour on an individual agent when the real problem is upstream.

1. Check Fleet Server's own health first. In Kibana, go to Fleet > Agents and filter to the policy running Fleet Server itself. If that agent is also offline or unhealthy, stop troubleshooting individual endpoints and work the Fleet Server host instead.
2. Run elastic-agent status on the affected host. This reports the agent's own view of its health, including whether it believes it is connected to Fleet Server, independent of what Kibana displays. A mismatch between what the host reports and what Kibana shows is itself a useful signal.
3. Check the service and its recent history. On systemd hosts: systemctl status elastic-agent and journalctl -u elastic-agent -n 200 --no-pager, paying specific attention to the boot-time window, not just the current moment.
4. Read the agent's own logs. On a Linux tar or package install, logs live under /var/log/elastic-agent/ or /opt/Elastic/Agent/data/elastic-agent-*/logs/elastic-agent-json.log; on Windows, under C:\Program Files\Elastic\Agent\data\elastic-agent-*\logs. Look for connection errors, TLS handshake failures, or DNS resolution failures clustered right around boot time.
5. Confirm basic network reachability to Fleet Server from the affected host: DNS resolution of the Fleet Server hostname, and a direct check of the Fleet Server API port, for example curl -k https://<fleet-server-host>:8220/api/status. If this fails right after boot but succeeds a minute later when you retry it manually, that supports the network-race explanation.
6. Pull a full diagnostics bundle before you change anything. Run elastic-agent diagnostics collect on the host. This is the same artifact Elastic's own maintainers ask for on both the GitHub issue and the Discuss thread, and having it ready before you start making changes saves you from having to reproduce the failure a second time if you end up needing to escalate.

Apply these in order of how invasive they are, confirming with the diagnostics above at each step whether the underlying condition has actually changed rather than just restarting things until the status flips.

• If Fleet Server itself was unhealthy: resolve that first, generally by confirming the Elasticsearch cluster it writes to is reachable and healthy, then restarting the Fleet Server host's agent service. Endpoint agents downstream often recover on their own once Fleet Server is healthy again, with no per-agent action needed.
• If the network-race pattern matches: fix the systemd unit ordering so elastic-agent does not start until the network stack is genuinely usable, not just present. Add or verify After=network-online.target and Wants=network-online.target in the elastic-agent systemd unit (or an override drop-in), rather than relying on the default network.target ordering, which only guarantees the network subsystem has started, not that it is usable.
• If a plain restart is worth trying: systemctl restart elastic-agent is the fix Elastic's own maintainer suggested on the Discuss thread. It is a reasonable first, low-cost step, but treat the fact that it did not work for that reporter as a real data point: if a restart does not clear the status within one or two checkin intervals, move on rather than repeating it.
• If local agent state looks corrupted: unenroll and re-enroll the agent (elastic-agent uninstall followed by a fresh install and enrollment, or elastic-agent unenroll --force where supported by your version) rather than trying to repair state files by hand.
• If you are on an affected version: check whether your Elastic Agent version predates the fix referenced by the closed GitHub issue (tracked against 8.7.0 BC5) and upgrade if so. A version-specific status-reporting bug is not something a configuration change on your end will resolve.

A status that flips back to healthy after a manual restart is not the same as a fix that survives an actual reboot. Do not close this out until you have confirmed the second half.

• Reboot the affected host deliberately (do not wait for the next scheduled maintenance window to find out) and watch Fleet > Agents in Kibana through at least two full checkin intervals after boot.
• Confirm elastic-agent status on the host reports a healthy, connected state, and cross-check that this matches what Kibana shows, not just that Kibana eventually turns green.
• Tail the agent log through the boot window again and confirm the connection errors you saw before are gone, not just that the final status happens to look fine.
• If you changed the systemd unit ordering, verify the change actually took effect after reboot: systemctl show elastic-agent -p After should list network-online.target, and the service's start timestamp in journalctl should trail the network coming up, not precede it.
• If you re-enrolled the agent, confirm it shows under its expected policy with a new agent ID in Fleet, and that the old, stale agent entry is either gone or explicitly unenrolled so it does not clutter future health checks.

Be honest with yourself about what a failed fix is telling you.

• Restart works once, then the problem recurs on the next reboot. This points away from a one-time glitch and toward the systemd ordering or stale-state explanations. Revisit those before repeating the restart.
• Systemd ordering fix does not change anything. This suggests the block is not a network race at all, and is more likely stale local state, a genuine version bug, or an upstream Fleet Server problem you have not fully ruled out yet. Go back to step one of diagnostics and re-check Fleet Server's own health.
• Restart does not help at all, as in the Discuss thread. Do not keep retrying the same restart expecting a different result. The reporter in that thread tried it multiple times without success and the thread closed without a confirmed fix, which is itself the honest state of this issue in some environments: Elastic's own community has an unresolved case that looked identical to a case with a known, patched cause.
• The problem is confined to one host among many otherwise-healthy agents. This argues against a systemic Fleet Server or version issue and toward something host-specific: a cloned VM image with duplicated agent state, a host-level firewall or DNS change, or a hardware clock or time-sync problem that breaks TLS handshake timing at boot.

Escalate rather than continuing to iterate on your own when any of the following are true:

• You have confirmed Fleet Server itself is healthy, ruled out the network-race and stale-state explanations with the diagnostics above, and the agent still will not report healthy after a clean reboot.
• The symptom is happening across multiple hosts on the same Elastic Agent version, which looks more like the version-specific bug pattern from the GitHub issue than a per-host misconfiguration.
• You have already collected an elastic-agent diagnostics collect bundle from an affected host during (or immediately after) the failure. Have this ready before you open the case; it is exactly what Elastic's own maintainers asked for on both the GitHub issue and the Discuss thread, and not having it ready is the single biggest reason these threads stall out unresolved, as the Discuss thread itself shows when the reporter struggled to share diagnostics through the forum's upload limits.
• Have your exact Elastic Agent and Fleet Server versions, host OS and version, the systemd unit configuration (or equivalent for your init system), and the log excerpt from the boot window ready alongside the diagnostics bundle. A support engineer working from a full diagnostics bundle and a precise boot-time log window can usually tell within one round trip whether you are looking at a known, patched bug or something host-specific that needs deeper investigation.

One more thing worth flagging while you have Fleet open: an agent that is stuck offline is a data-plumbing problem, but it is a different problem from whether the detection rules running on top of that data actually fire once the pipeline is healthy again. If you are troubleshooting agent health as part of a broader push to trust your SIEM's coverage, Detection Posture Management: CardinalOps vs. SOC Prime vs. Anvilogic covers that separate, downstream question.