Appearance
Logs
Status: present state, partial. There is no
hivecast logssubcommand; the wrapper's help text doesn't list one. Logs live as plain text files under the Host home (and as journald output for systemd-managed Hosts). This page documents the actual locations and the recipes operators use today.
Per-runtime logs
<host-home>/logs/runtimes/
├── RUNTIME-HOST-SYSTEM.stdout.log
├── RUNTIME-HOST-SYSTEM.stderr.log
├── RUNTIME-HOST-GATEWAY.stdout.log
├── RUNTIME-HOST-GATEWAY.stderr.log
├── RUNTIME-HOST-CHAT.stdout.log
└── ...Each supervised runtime gets its own pair of log files keyed by runtime id. CLAUDE.md lists this layout under "Host state and logs":
<host-home>/host.status.json,<host-home>/runtimes/*.json,<host-home>/credentials/hivecast-link.json,<host-home>/credentials/hivecast-install.json, and<host-home>/logs/runtimes/.
To follow:
bash
tail -f <host-home>/logs/runtimes/<runtimeId>.stdout.logTo get the last N lines of a stopped runtime:
bash
tail -n 200 <host-home>/logs/runtimes/<runtimeId>.stderr.logHost-level logs
For non-systemd installs, the Host process itself writes to:
<host-home>/logs/host.stdout.log
<host-home>/logs/host.stderr.logFor systemd-managed Hosts (the Ubuntu .deb installer path), use journald:
bash
journalctl -u hivecast-host.service -f # follow
journalctl -u hivecast-host.service -n 500 # last 500 lines
journalctl -u hivecast-nats.service -f # the sibling NATS processNATS logs
The bundled NATS sibling process logs to its own data directory (declared in host.json:transport.nats.dataDir, default <host-home>/nats/host-default/):
<host-home>/nats/host-default/nats-server.log
<host-home>/nats/host-default/nats-server.pidFor systemd installs, journald: journalctl -u hivecast-nats.service -f.
Why logging happens through actorLog
CLAUDE.md Rule 9.4 forbids console.log in actor code. Use actorLog(). Reasons:
- Identity:
actorLogcarries the actor's mount and runtime id, so a bus-wide log stream can correlate entries. - Routing: bus-native logs can be subscribed to by an operator actor (
smithers,system.observability). - Discipline: keeping
console.logout of actor code prevents stdout pollution from breaking the runner's structured output when running with--json.
The output of actorLog ends up in stdout/stderr of the runtime, which means it ends up in <host-home>/logs/runtimes/<runtimeId>.{stdout,stderr}.log like any other runtime output.
Common log triage recipes
bash
# 1. Which runtime crashed?
ls -lt <host-home>/logs/runtimes/
# 2. Why did it crash?
tail -n 500 <host-home>/logs/runtimes/<runtimeId>.stderr.log | less
# 3. Did the Host see the crash?
hivecast runtimes --home <host-home> | jq '.[] | select(.runtimeId=="<runtimeId>")'
# 4. Are runtime records corrupt?
hivecast seed
# corrupt[] in the output points to zero-byte or unparseable runtime.json files
# 5. systemd-level failures
journalctl -u hivecast-host.service --since "1 hour ago"Target state — hivecast logs
Status: target state.
A unified log command would aggregate Host + runtime logs through one pager and accept a runtime selector. Today the workaround is tail/journalctl per source. None of this is in code.
See also
- Running → Health
- Running → Verify
projects/matrix-3/packages/docs-hivecast/content/cli/exit-codes-and-diagnostics.mdfor exit-code semantics that complement log triage
Source: Log paths come from the Host config layout enforced by
projects/matrix-3/packages/host-service/src/cli.tsand theruntimeStorage/logsDirfields inhost.json.