# `:diagnose`
Dump the cockpit's current snapshot + recent HTTP log to a
text file. The thing you attach to a support thread.
```
:diagnose
:diag (alias)
```
## What it captures
Three sections, in this order:
1. **Profile** — the active node's name + URL.
2. **Health gates** — every S1 gate's status and value at
the moment of capture. So if a reviewer asks "what was
bin saturation showing?" you don't need to remember; it's
in the bundle.
3. **Last 50 API calls** — most recent entries from the
live LogCapture buffer. Method, path, status, elapsed.
The output looks like:
```
# bee-tui diagnostic bundle
# generated UTC 2026-05-07T08:14:32Z
## profile
name prod-1
endpoint http://10.0.1.5:1633
## health gates
✓ API reachable last_ping 34ms
✓ Chain RPC block 234,512 / tip 234,514 (Δ +2)
✓ Wallet funded BZZ 12.50 · native 0.0421 ETH
⚠ Bin saturation 2 starving: bin 4, bin 5
...
## last API calls (path only — Bearer tokens, if any, live in headers and aren't captured)
08:14:01.123 GET /health 200 34ms
08:14:01.456 GET /chainstate 200 18ms
...
## generated by bee-tui 1.0.0
```
## Where the file goes
`$TMPDIR/bee-tui-diagnostic-<unix-timestamp>.txt`. On Linux
that's typically `/tmp/`. The cockpit prints the full path
in the status line:
```
diagnostic bundle exported to /tmp/bee-tui-diagnostic-1715056472.txt
```
Each invocation gets its own timestamp; you can run
`:diagnose` multiple times in a session and not overwrite
the earlier capture.
## What's NOT captured
This is the important part — the bundle is safe to share:
- **Bearer tokens.** They live in HTTP `Authorization`
headers; LogCapture only sees method + URL. Tokens *never*
appear in the file.
- **Request / response bodies.** Only metadata (status code,
elapsed time) is in the buffer.
- **Wallet private keys.** Bee doesn't expose them via the
API and the cockpit never asks.
- **Anything from your `config.toml`** beyond the active
profile name + URL. The TOML file itself is not read into
the bundle.
You can paste the bundle into a public GitHub issue, a
support email, or a Discord help channel without redacting.
## When to use it
- **Bug report**: paste the bundle into the issue body.
Reviewers see what your node actually looked like at the
moment of the bug, not just your description.
- **Operator handoff**: when transferring node ownership,
capture a baseline "what does normal look like" bundle.
- **Before a risky operation**: backup the current state.
Doesn't roll back anything; just records what was true.
## What to compare against
Two bundles, 5 minutes apart, are a quick diff for "did
anything change?". Just `diff` them.
For longer-term comparison, save bundles per day; the
elapsed columns let you see whether call latency drifted.
## See also
- [The `:command` bar](./bar.md)
- [S1 — Health gates](../screens/s1-health.md) (the gates
you'll see in the bundle)
- [S10 — Command log](../screens/s10-log.md) (the live
version of the "Last API calls" section)