Troubleshooting
Most setup problems come down to one of four things: the host cannot reach Breach360, the installer could not finish, the foothold is installed but not running, or you cannot get into the platform to look. This section covers each in turn.
Start with the checks on this page. They narrow the problem to one of the pages below in a couple of minutes, and they are worth running before you contact support, because the answers are the first thing we will ask for.
Start here: four checks
1. What does the deployment status say?
Open Deploy and look at the deployment's status. Each status means something specific, and the meaning narrows the problem considerably.
| Status | What it means | Where to look |
|---|---|---|
| Not Set Up | The deployment record exists, but no foothold has ever contacted the platform with its secret. | Installation |
| Initializing | The foothold is running and has made contact, but is still starting up — usually downloading its container image. | Deployment Health |
| Probing | The foothold is checking what it can reach on the local network. | Normal; no action needed |
| Ready | The foothold is healthy and available for engagements. | Nothing is wrong with the deployment itself |
| Engaged | The foothold is currently running an engagement. | Normal; no action needed |
| Offline | The foothold made contact at some point, but has since gone quiet. | Deployment Health |
Not Set Up and Offline are different problems. Not Set Up means the platform has never heard from this foothold, so the fault is in installation or in the outbound path. Offline means it did reach the platform and then stopped, so the software is installed and the outbound path worked at least once.
2. Can the host reach the platform at all?
Run this on the host machine itself, not on your laptop:
curl -I https://aev.breachlocklabs.com
For POV (proof-of-value) customers, test the demo host instead:
curl -I https://aev-demo.breachlocklabs.com
Any HTTP response — including 401 or 403 — means the host reached us. A timeout, a DNS failure or
a certificate error does not. See Host Connectivity.
3. Is the foothold process actually running?
Use the command for the way you deployed it.
| Deployment method | Command |
|---|---|
| Dropper install on a Linux host | systemctl status frontier |
| OVA appliance | systemctl status frontier, from the OVA's terminal |
| Docker container deployment | docker ps |
If the service is not running, see Deployment Health.
4. What do the logs say?
The foothold reports to the platform as well as writing to disk, so the on-host logs are the place to look when nothing is reaching the platform at all.
| Deployment method | Log location |
|---|---|
| Dropper install on a Linux host | journalctl -u frontier -n 200 --no-pager |
| Linux host with no working systemd (fallback mode) | /etc/frontier/frontier.log |
| OVA appliance | journalctl -u frontier -n 200 --no-pager |
| Docker container deployment | docker logs <container-id> |
What to send us
If the four checks above have not resolved it, collect the following before contacting support. It is almost always enough for us to diagnose without a call:
- The deployment name, and the status shown in the platform.
- The output of
curl -I https://aev.breachlocklabs.comfrom the host. - The last 200 lines of the foothold log (see the table above).
- The operating system and architecture, from
uname -aon the host. - Which deployment method you used — dropper install, OVA appliance, or Docker container.
Still stuck? Reach out to your BreachLock representative, or email us at support@breachlock.com. Include the details above and we can usually tell you what is wrong without needing a call.