Skip to content

Deployment Health

Symptoms covered on this page

  • A deployment shows Offline, or flaps between Offline and Ready.
  • A deployment sits in Initializing and never reaches Ready.
  • The foothold service is stopped, or will not start.
  • The foothold was working and then stopped after a reboot, an update, or a security scan.
  • A deployment is Ready, but engagements find nothing on the network.

If the deployment has never reached the platform at all — it still reads Not Set Up — this is the wrong page. Start with Installation.

A deployment shows Offline

Offline is derived, not reported. The foothold polls the platform continuously, so the platform marks a deployment Offline when it has not heard from it for one minute. A deployment that shows Offline therefore installed correctly and reached us at least once, and something has since stopped it talking.

Work through these in order:

  1. Is the host powered on and on the network? The most common answer, and the quickest to rule out.
  2. Is the service running? See The foothold service is not running.
  3. Can the host still reach the platform? Run curl -I https://aev.breachlocklabs.com on the host. A firewall rule, a certificate rotation on an inspection appliance, or a DNS policy change will all present exactly like this. See Host Connectivity.
  4. Did something stop the process? Check the foothold log and the host's security logs. See Endpoint protection.

A deployment that flaps between Offline and Ready

Intermittent status usually means the host is reaching us but unreliably. Likely causes, roughly in order of how often they turn out to be the answer:

  • The host sleeps or suspends. A laptop used as a foothold will go Offline every time its lid closes. Use a machine that stays awake, or the OVA appliance.
  • A saturated or lossy link, particularly over Wi-Fi or a VPN.
  • A load-balanced egress path where only some routes have the Breach360 hostnames allowlisted. This is a distinctive one: it produces a deployment that is Offline for a minute at a time at irregular intervals, with nothing wrong on the host at all.

The View Telemetry screen on the deployment's context menu shows contact history and live operational metrics, which is the fastest way to tell a host that is flapping from one that went down once.

A deployment stays in Initializing

Initializing means the foothold has made contact and is starting up. The step that takes the time is downloading its container image, which is measured in gigabytes — so the platform allows a full hour of silence in this state before calling a deployment Offline, rather than the usual minute.

An hour is generous on purpose. If a deployment has genuinely been Initializing for longer than that:

# Is the image download making progress? The log reports a percentage as it goes.
journalctl -u frontier -n 100 --no-pager

# Is there room for it?
df -h /

# Did the image land?
docker images

The usual answers are that the host ran out of disk part-way through the download, or that Docker is not usable by the account the foothold runs as — see Docker and the container runtime.

The foothold service is not running

Checking the service

Deployment method Command
Dropper install on a Linux host systemctl status frontier
OVA appliance systemctl status frontier
Docker container deployment docker ps

If the host has no working systemd, the installer falls back to starting the foothold as a background process instead of a service. In that case there is no unit to query — check for the process and its recorded PID:

cat /etc/frontier/frontier.pid
ps -p "$(cat /etc/frontier/frontier.pid)"
tail -n 100 /etc/frontier/frontier.log

A foothold started this way does not survive a reboot. If a deployment reliably goes Offline every time the host restarts, this is almost always why.

Restarting the foothold

Deployment method Command
Dropper install on a Linux host sudo systemctl restart frontier
OVA appliance sudo systemctl restart frontier
Docker container deployment docker restart <container-id>

Stopping the process is not the same as stopping the service. The systemd unit is configured to restart the foothold a second after it exits, so killing the process — including via the Kill Process action in the deployment context menu — leaves systemd to bring it straight back. To keep a foothold down, stop the service itself with sudo systemctl stop frontier.

The service will not start

Read the failure rather than guessing at it:

systemctl status frontier --no-pager
journalctl -u frontier -n 200 --no-pager

Two causes account for most of these:

  • The binary is missing or not executable. The installer places it at /etc/frontier/frontier. Endpoint protection quarantining the binary produces exactly this.
  • The deployment secret is gone. The secret is baked into the unit's ExecStart line. If the unit file was edited or regenerated by hand, the foothold will start and fail to authenticate.

Endpoint protection is stopping the foothold

The foothold installs and runs penetration-testing tooling — nmap, masscan, tshark, and a container image full of exploitation tools. Endpoint detection and response products classify that behaviour as malicious, because in every other context it is.

The symptoms are distinctive: the installer's download fails for no apparent network reason, the foothold binary vanishes from disk, or the service starts, runs for a short period, and is killed without writing an error of its own.

Add an exclusion for the foothold rather than disabling protection on the host. The host is inside your network and should stay protected; an exclusion is narrower and is something you can leave in place.

The foothold installs to /etc/frontier/, so that is the directory to exclude. You may also need to exclude the tooling it installs alongside itself — nmap, masscan, tshark and sshpass — and to permit Docker to pull and run the sapiens-container image.

Check your endpoint product's own quarantine log to confirm before changing anything — it will name exactly what it removed, which saves adding exclusions you did not need.

A deployment is Ready but engagements find nothing

A Ready deployment means the foothold is healthy and can talk to us. It says nothing about what the foothold can see on your network.

Use Map Network from the deployment's context menu to find out what it can reach. If the map comes back nearly empty, the foothold is probably not on the segment you intended:

  • Check which interface and subnet the host is on with ip addr. A foothold on a management or guest VLAN typically cannot reach the estate you want tested.
  • Specify the range explicitly. Map Network accepts a CIDR or network range, so you can confirm whether a specific subnet is reachable rather than relying on what the host can infer.
  • Consider the scan intensity. Stealth and Quiet intensities are deliberately slow and gentle; on a large or filtered network they may return very little. Raise the intensity if the environment allows it.
  • Check for host-based filtering between segments. Internal firewalls and micro-segmentation are frequently the answer, and finding that out is itself a useful result.

After an update or a reboot

The foothold updates itself from the platform, which replaces its binary and restarts it. A short Offline period around an update is expected. If it does not come back:

  • Confirm the service is enabled to start at boot — systemctl is-enabled frontier. A foothold started in the non-systemd fallback mode is not.
  • Confirm endpoint protection did not quarantine the newly written binary. A product that has learned to accept the old binary will not necessarily accept the new one.
  • Confirm the host still has disk space for the replacement image.

Need help? Send us the deployment name, the status shown in the platform, and the last 200 lines of the foothold log — see What to send us. Reach out to your BreachLock representative or email support@breachlock.com.