---
title: "Observability"
url: "https://control.actana.ai/docs/reference/observability"
description: "Where logs land for every way of running it, and the log lines worth grepping. No metrics endpoint."
updated: 2026-09-01T09:03:21+00:00
---

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

- [HTTP surfaces](/docs/reference/http-surfaces) — `GET /api/healthz` on the Panel; hook receiver on the Core.
- [Environment variables](/docs/reference/environment-variables) — `ACTANA_UPDATE_CHECK`.
- [Operating a Core](/docs/core/operating) — status, logs, update.