Observability

The Panel and each Core log to stdout/stderr. Whoever supervises the process owns the sink. There is no metrics endpoint and no tracing exporter. The Panel holds no task-shaped state to report on — each Core owns its own — so the useful signal is the process log plus actana status on the machine in question.

How you run it Where the logs are
Compose / Docker docker compose logs panel, docker compose logs core
systemd user unit (Linux Core) journalctl --user -u actana-core
LaunchAgent (macOS Core) actana logs tails ~/Library/Logs/Actana/core.log
Foreground (pnpm start) the terminal you started it in

On any Core, actana logs (-f to follow) reads the daemon's log wherever it lands. actana status is the healthcheck: it prints the Core's health, its endpoint, whether this Core has pairing material yet, and — when one exists — whether a newer release is available.

A containerised Core refuses actana logs and names docker compose logs -f core instead. Status, pair, and harness install still work there.

Lines worth grepping

A Core says something when a Session's status is decided by something other than the harness reporting it. All of them are ordinary log lines — there is no counter to scrape:

Line What it means
hook-delivery.missed a hook's POST never got an ack; the line names the task, the event, and curl's exit
hook-delivery.missed-total how many drops this Core has seen since boot — one a week is a flake, forty in an hour is a Core losing to its own load
session-sweep.settled rows a Core restart stranded, marked disconnected at boot
session-backstop.settled a Session settled because its turn went quiet and no Stop ever arrived

Missed hook deliveries are recorded by the hook itself into <user-data-dir>/hook-misses.log and drained into the log from there, so drops that happened while the Core was down show up on its next boot.

See also

Built by Qcentic