: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