# Troubleshooting

> Fix a Whisper endpoint: a running sensor that ships nothing, sudo losing your key, a host listed twice, a rule that never fires, a blank console.

*Source: https://www.whisper.security/docs/endpoint/troubleshooting*

---
Read this first, in this order:

```bash
whisper status
whisper service status --sensor
journalctl -u whisper-sensor -n 3
```

The first says whether a key is in effect and which agent is selected. The second says whether the service is installed, running, and reporting under an address. The third says what the sensor itself thinks.

## The service is running and nothing arrives

The journal says what is missing:

```text
whisper: no bound /128 identity - summaries stay local until one is bound
```

The machine is collecting normally and holding everything locally, because it has no address to ship under. Bind it and restart:

```bash
whisper enroll
sudo -E whisper service restart --sensor
```

Then confirm you see `reporting as` with your address. This is the most common cause by a wide margin: `active (running)` only ever meant that the process started. [Bind the host](/docs/endpoint/install/enroll) is the whole step.

## The service starts with no identity even though you bound the host

You used `sudo` without `-E`. `sudo` resets `HOME`, and both your key and the bound marker live under your home directory, so root looked somewhere else and found neither. Re-run the install or the restart with the environment kept:

```bash
sudo -E whisper service install --now --sensor
```

## The installer said the key was refused

The CLI is installed and usable; only the keyed part did not happen. Sign in and bind by hand:

```bash
whisper login --web
whisper enroll
```

## The host appears twice in the roster

Binding ran twice under two different names, and each name gets its own address. `whisper enroll` is idempotent under one name, so bind under the name that is already registered:

```bash
whisper enroll --name <the-registered-name>
```

The duplicate keeps its address until you revoke it; [contain an endpoint](/docs/endpoint/operate/contain) has that command, and it is permanent.

## `whisper` is not on the PATH

The installer puts the binary in `/usr/local/bin` when it runs as root and in `~/.local/bin` otherwise. Call it by its full path, or reinstall with `WHISPER_DIR` set to somewhere already on your PATH. This is also why an install step and a `sudo` step can disagree about where the binary is: give `sudo` the full path.

## A configuration change had no effect

`sensor.json` is read when the service starts. Apply it:

```bash
sudo -E whisper service restart --sensor
```

Remember that the file can only narrow: a key is on unless it is explicitly `false`. See [what the sensor detects](/docs/endpoint/operate/detections).

## DNS questions are missing from a host's activity

The sensor attributes the plain DNS the host itself sends. Name resolution the machine sends over an encrypted transport is answered by the Whisper resolver instead, so those questions, and the verdicts on them, arrive on the resolver's side rather than through on-host attribution:

```bash
whisper logs --kind dns
```

[Encrypted DNS](/docs/network/resolver/encrypted-dns) is how to point a host there deliberately.

## A rule I added never fires

Check that the rule's log source maps to an event kind the collectors emit, that the condition is written against a single event rather than a sequence, and that the service was restarted after the file was copied in. [Add your own rules](/docs/endpoint/operate/rules) has the mapping.

## Windows: the service is not there

Install from an elevated PowerShell, under the same account that ran `whisper enroll`, since the marker lives in that account's profile. Then:

```powershell
sc query whisper-sensor
whisper service status --sensor
Get-Content C:\ProgramData\Whisper\logs\whisper-sensor.log -Tail 20 -Wait
```

## The console shows nothing

Each signed-in operator resolves to their own key and sees their own estate only, and an estate with nothing provisioned renders empty rather than failing. If a host you expect is missing, it is a binding question rather than a console one: start at the top of this page.

## I need to prove a containment held

Read the action back rather than trusting the call that made it. The read-back of the firewall in [contain an endpoint](/docs/endpoint/operate/contain) is the evidence for a hold, and [the transparency log](/docs/identity/transparency) is the evidence for a cut.