EDR agent unhealthy or offline on some machines: fast diagnosis

TL;DR — When only some machines show an EDR agent as unhealthy or offline, the most common causes are: the local agent service is stopped/crashing, outbound HTTPS to the vendor cloud is blocked or intercepted, or the machine was cloned/reimaged and kept a stale agent identity. Start local: check the service and logs, then test DNS/TLS/proxy egress from the affected host, then re-register the agent only after you know connectivity is clean. Reading time: ~6 min

The scenario

It is Tuesday at 3:40 PM. A handful of laptops and two build runners suddenly show as offline in your EDR console, but most of the fleet is green. The affected users can browse the web and VPN works, so the first instinct is "dashboard glitch"—until one machine also stops receiving policy updates and its last check-in is 9 hours ago. You need a short path to determine whether this is a dead local service, broken egress, TLS interception, or a bad clone image before you burn time reinstalling agents blindly.

Symptoms

• In the EDR console, endpoint status is one of:
  • Offline
  • Unhealthy
  • Last seen: 6h ago / Last check-in failed
• Local service is stopped or flapping:

$ systemctl status edr-agent
● edr-agent.service - Endpoint Detection Agent
     Loaded: loaded (/usr/lib/systemd/system/edr-agent.service; enabled)
     Active: activating (auto-restart) (Result: exit-code) since Tue 2026-10-30 15:42:11 UTC; 2s ago
    Process: 28144 ExecStart=/opt/edr/bin/agent --foreground (code=exited, status=1/FAILURE)

• Windows Service Control Manager shows repeated restarts:

PS> sc.exe query edragent
STATE              : 1  STOPPED
WIN32_EXIT_CODE    : 1067  (0x42b)
SERVICE_EXIT_CODE  : 1  (0x1)

• Agent logs show network or TLS failures:

dial tcp: lookup api.vendor.example: no such host
x509: certificate signed by unknown authority
proxyconnect tcp: tls: first record does not look like a TLS handshake
i/o timeout
context deadline exceeded
HTTP 407 Proxy Authentication Required
HTTP 403 Forbidden

• curl to the vendor API or enrollment/check-in URL fails from affected hosts but works elsewhere:

$ curl -Ivs https://api.vendor.example/
* CONNECT tunnel failed, response 407
< HTTP/1.1 407 Proxy Authentication Required

• Or TLS interception is obvious:

$ openssl s_client -connect api.vendor.example:443 -servername api.vendor.example </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject
issuer=CN = Corporate TLS Inspection Root
subject=CN = api.vendor.example

• Duplicate/stale registration symptoms after imaging/cloning:
  • Two hosts share the same hostname/agent ID in the console
  • One host flips between online and offline
  • Reimaged machine never appears as a new endpoint after reinstall

Likely causes

Step-by-step diagnosis

[Affected Host] ---- 1. service status ----> [Agent Process]
      |
      | 2. curl/openssl
      v
[DNS/Proxy/TLS] ---- 3. reachable? ----> [Vendor Cloud]
      |
      | 4. identity/state
      v
[Local Agent ID] ---- 5. duplicate? ----> [Console Record]

1. Check whether the local service is actually running.

sudo systemctl status edr-agent --no-pager
sudo journalctl -u edr-agent -n 50 --no-pager

This is your problem if you see Active: failed, activating (auto-restart), status=1/FAILURE, segmentation fault, or repeated restart throttling like Start request repeated too quickly. Jump to Fixes → Local agent service stopped, crashing, or disabled.

On Windows:

Get-Service -Name *edr* | Format-Table -Auto
Get-WinEvent -LogName Application -MaxEvents 50 | ? {$_.ProviderName -match 'edr|application error'} | Select TimeCreated, ProviderName, Id, LevelDisplayName, Message

If the service is Stopped or Application Error events mention the agent binary/DLL, jump to the same fix.

1. Test outbound connectivity from the affected host, not from your laptop.

curl -Ivs https://api.vendor.example/
nslookup api.vendor.example

This is your problem if you get Could not resolve host, Connection timed out, No route to host, or a proxy response like HTTP/1.1 407 Proxy Authentication Required. Jump to Fixes → Outbound DNS/HTTPS blocked or Fixes → Proxy misconfiguration.

A healthy shape usually looks like:

$ curl -Ivs https://api.vendor.example/
* Connected to api.vendor.example (203.0.113.24) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
< HTTP/2 200
< content-type: application/json

A redirect is not automatically bad, but if it downgrades or loops, it is:

$ curl -Ivs http://api.vendor.example/
< HTTP/1.1 301 Moved Permanently
< Location: https://api.vendor.example/

That is fine. This is not:

< HTTP/1.1 302 Found
< Location: http://proxy.local/login

1. Check for proxy settings and whether the agent inherits them.

env | grep -i _proxy
systemctl show edr-agent -p Environment

This is your problem if the host has HTTPS_PROXY=http://proxy.local:8080 but the proxy requires auth or only some subnets can use it, or if NO_PROXY incorrectly includes the vendor domain. Jump to Fixes → Proxy misconfiguration or proxy auth required.

On Windows:

netsh winhttp show proxy
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable,ProxyServer,AutoConfigURL

1. Validate TLS without the browser masking the issue.

openssl s_client -connect api.vendor.example:443 -servername api.vendor.example </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

This is your problem if the issuer is your corporate inspection CA when the agent expects the public vendor cert chain, or if dates are invalid. Jump to Fixes → TLS interception / missing CA or Fixes → System clock skew.

1. Check clock skew.

timedatectl status

This is your problem if System clock synchronized: no, the time is off by minutes, or timezone/NTP is broken. TLS and token validation can fail long before users notice. Jump to Fixes → System clock skew.

On Windows:

w32tm /query /status

1. Check for duplicate identity or stale registration after imaging.

cat /etc/machine-id
sudo ls -l /var/lib/edr /etc/edr 2>/dev/null

This is your problem if multiple cloned machines share the same machine-id or copied agent state directory, or the console shows one endpoint record flapping between hosts. Jump to Fixes → Duplicate/stale agent identity.

1. Check disk pressure and local write failures.

df -h / /var
journalctl -u edr-agent -n 100 --no-pager | egrep -i 'no space|read-only|permission denied'

This is your problem if /var or the agent state volume is full, or logs show write failures. Jump to Fixes → Endpoint overloaded or disk full.

Fixes

Local agent service stopped, crashing, or disabled

Linux:

sudo systemctl enable --now edr-agent
sudo systemctl reset-failed edr-agent
sudo journalctl -u edr-agent -n 100 --no-pager

If it still exits immediately, inspect the unit and binary path:

systemctl cat edr-agent
sudo /opt/edr/bin/agent --version

If the binary is missing/corrupt after a partial upgrade, reinstall using your package source:

sudo apt-get update && sudo apt-get install --reinstall edr-agent
# or
sudo dnf reinstall edr-agent

Windows:

Set-Service -Name edragent -StartupType Automatic
Start-Service -Name edragent

If it still fails with 1067, repair/reinstall from your software distribution tool.

Verify it worked:

systemctl is-active edr-agent && journalctl -u edr-agent -n 20 --no-pager | tail

Outbound DNS/HTTPS to vendor cloud blocked by firewall/VPN split-tunnel

Allow outbound TCP/443 and DNS from affected subnets to the vendor endpoints documented by your EDR provider. If you manage host firewall locally, test by temporarily allowing egress.

Linux with ufw:

sudo ufw allow out 53
sudo ufw allow out 443/tcp

Linux with firewalld:

sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-service=dns
sudo firewall-cmd --reload

If the issue only appears on VPN, add the vendor domains/IP ranges to split-tunnel allow rules in your VPN/firewall policy, then reconnect VPN.

Verify it worked:

curl -Ivs https://api.vendor.example/ | egrep 'HTTP/|SSL connection'

Proxy misconfiguration or proxy auth required

If the agent uses systemd and should inherit a proxy, set it explicitly in a drop-in instead of relying on shell profiles.

sudo mkdir -p /etc/systemd/system/edr-agent.service.d
sudo tee /etc/systemd/system/edr-agent.service.d/proxy.conf >/dev/null <<'EOF'
[Service]
Environment="HTTPS_PROXY=http://proxy.local:8080"
Environment="HTTP_PROXY=http://proxy.local:8080"
Environment="NO_PROXY=127.0.0.1,localhost"
EOF
sudo systemctl daemon-reload
sudo systemctl restart edr-agent

If the proxy requires authentication, use your supported machine-auth method; do not hardcode personal credentials into a unit file unless your security policy explicitly allows it.

If the proxy is the problem, clear it for a test:

sudo systemctl unset-environment HTTPS_PROXY HTTP_PROXY NO_PROXY
sudo systemctl restart edr-agent

Trade-off: bypassing the proxy may violate egress policy; use only as a short diagnostic.

Verify it worked:

systemctl show edr-agent -p Environment
curl -Ivs https://api.vendor.example/

TLS interception / missing corporate root CA for the agent runtime

If your network performs HTTPS inspection, either bypass inspection for the EDR vendor domains or install the corporate root CA into the OS trust store used by the agent.

Debian/Ubuntu:

sudo cp corp-root-ca.crt /usr/local/share/ca-certificates/corp-root-ca.crt
sudo update-ca-certificates
sudo systemctl restart edr-agent

RHEL/Fedora:

sudo cp corp-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust
sudo systemctl restart edr-agent

Windows (Local Machine root store):

certutil -addstore -f Root C:\Temp\corp-root-ca.cer
Restart-Service edragent

Trade-off: trusting an inspection CA fixes connectivity but weakens end-to-end certificate guarantees. Prefer a no-inspection exception for EDR traffic where policy allows it.

Verify it worked:

openssl s_client -connect api.vendor.example:443 -servername api.vendor.example </dev/null 2>/dev/null | openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt

System clock skew

Linux:

timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd || sudo systemctl restart chronyd || true
timedatectl status

Windows:

w32tm /resync /force
w32tm /query /status

If the VM resumes from snapshots often, also fix the hypervisor time-sync policy so the guest does not drift after resume.

Verify it worked:

date -u && timedatectl status | egrep 'synchronized|NTP service'

Duplicate/stale agent identity after clone/reimage/snapshot rollback

⚠️ This can create a new endpoint record and may break historical linkage in your EDR console. If you need to preserve forensic continuity, export or note the old record before re-registering.

On golden images, remove machine-specific IDs and agent state before sealing the image. On an already-bad clone, stop the agent, clear its identity/state, regenerate machine identity if appropriate, then start it so it enrolls cleanly.

Linux example:

sudo systemctl stop edr-agent
sudo rm -rf /var/lib/edr/* /etc/edr/agent-id 2>/dev/null
sudo rm -f /etc/machine-id
sudo systemd-machine-id-setup
sudo systemctl start edr-agent

Windows: remove the agent with your standard uninstall method, delete remaining agent state under its program data directory if your vendor documents that as supported, then reinstall so it registers as a new endpoint.

Verify it worked:

cat /etc/machine-id
journalctl -u edr-agent -n 50 --no-pager | egrep -i 'enroll|register|check-in|connected'

Endpoint overloaded or disk full

Free space on the state/log volume, then restart the agent.

df -h / /var
sudo journalctl --vacuum-time=7d
sudo find /var/log -type f -name '*.gz' -delete
sudo systemctl restart edr-agent

If CPU starvation is the issue on build runners, reduce competing workloads or raise service priority only if you understand the impact.

Verify it worked:

df -h / /var && systemctl is-active edr-agent

Prevention

• Add a host-level service check, not just console status. For Linux nodes in your fleet monitoring:

systemctl is-active --quiet edr-agent || exit 2

Alert on non-zero exit.

• Add a scheduled egress/TLS probe from representative subnets and VPN pools:

curl -fsS --connect-timeout 5 https://api.vendor.example/healthz >/dev/null || exit 2

Run it from office LAN, VPN, and cloud runner networks so split-tunnel mistakes show up before agents do.

• Pin proxy settings in the service manager, not in shell startup files. Keep a managed systemd drop-in or Windows GPO/MDM policy for the agent service environment so upgrades do not silently lose proxy config.
• In your image pipeline, strip machine-specific identity before sealing templates:

rm -f /etc/machine-id
rm -rf /var/lib/edr/* /etc/edr/*

Then regenerate on first boot. Add this as a CI/image-build step, not a wiki note.

• Monitor time sync drift on laptops and VMs. Example Linux check:

timedatectl show -p NTPSynchronized -p TimeUSec --value

Alert if NTP is unsynchronized for more than one polling interval.

• Maintain explicit firewall/TLS-inspection exceptions for your EDR vendor domains/IP ranges in your provider's dashboard or firewall manager (for example, in your firewall policy under Network Rules or TLS Inspection Exclusions). Review these rules whenever VPN, proxy, or secure web gateway policies change.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.