Binions gives you three ways to see what it is doing. Every daemon answers health checks, writes structured logs to the system journal, and — if you switch it on — emits traces to a bundled Jaeger collector. Health checks and logs are always on; tracing is optional and off by default.
All on your host. Health endpoints, logs, and traces stay on the machine Binions runs on. Nothing is sent to a vendor, and the tracing UI listens only on
localhost— you reach it over SSH.
Every daemon exposes three endpoints on the loopback interface (127.0.0.1), each on its own port in the 91xx range:
/health/live — is the process up and running at all?/health/ready — is the daemon ready to do work (connections open, state loaded)?/metrics — Prometheus-format counters and timings for that daemon.Check any daemon with a one-line curl. A successful readiness probe exits 0, so you can use it in scripts:
curl -sf http://127.0.0.1:9100/health/ready && echo OKEach daemon has a fixed port. A few of the common ones:
| Daemon | Health & metrics port |
|---|---|
| logger | 127.0.0.1:9100 |
| database | 127.0.0.1:9102 |
| mailbox | 127.0.0.1:9107 |
| playbook | 127.0.0.1:9108 |
| webhookcaller | 127.0.0.1:9109 |
| scheduler | 127.0.0.1:9110 |
The full port map and what each probe reports live in Health checks.
Every daemon writes structured JSON straight to the systemd journal, so you read its logs the same way you read any other service on your host — with journalctl:
# Follow the playbook daemon live
journalctl -u binions-playbook -f
# Last 200 lines from the mailbox daemon
journalctl -u binions-mailbox -n 200
# Everything from the logger daemon since this morning
journalctl -u binions-logger --since "09:00"binions-<name> — for example binions-logger, binions-mailbox, binions-scheduler.jq to filter on fields such as the event type or the correlation ID.Correlation IDs. Every event carries a correlation ID. Filter the logs by one ID and you see every step of a single workflow, in order, even when it crossed several daemons.
More on reading and filtering logs is in Reading logs, and the central audit sink is described in Logger service.
For deeper debugging, Binions bundles a Jaeger collector that turns those correlation IDs into a visual waterfall — a timeline showing how long each step of a workflow took, across every daemon it touched. Tracing is opt-in per daemon: a daemon only sends traces once you add an [otel] block to its application.toml. Without that block, the daemon runs in exactly the same way — it just logs JSON to the journal and produces no spans.
To turn tracing on for a daemon, add a block like this to its application.toml and restart the daemon:
[otel]
endpoint = "http://127.0.0.1:4317"
service_name = "playbook-service"
sample_rate = 1.0Keys shown are illustrative. The exact
[otel]keys and defaults for your release are listed in Per-daemon configuration — treat the snippet above as a shape, not a copy-paste config. The collector address (127.0.0.1:4317) is the one constant: that is where the bundled Jaeger listens for traces.
The Jaeger collector listens only on the loopback interface — OpenTelemetry traces arrive on 127.0.0.1:4317, and the web UI is served on 127.0.0.1:16686. Because the UI is loopback-only, you reach it from your laptop through an SSH tunnel:
# Forward the Jaeger UI to your local machine
ssh -L 16686:127.0.0.1:16686 you@your-binions-host
# then open http://127.0.0.1:16686 in your browserIn the UI, pick a service, search by a correlation ID, and you get the full span tree for that workflow — with the time spent in each step laid out so you can spot where the delay was. Jaeger is part of the free infrastructure tier, and you can leave it switched off until you actually need it.
The thread that ties everything together is the correlation ID. Each event Binions handles carries one, and it travels with the work as it moves from daemon to daemon. That gives you a single key to follow one whole workflow:
journalctl output by the correlation ID to see every event for that workflow, in sequence, regardless of which daemon emitted it.So a typical investigation is: read the structured logs first, grab the correlation ID of the run you care about, and — if you need timings — open that same ID in Jaeger. A worked walkthrough is in Reading logs & traces.
Tip. Tracing is optional and off by default. Turn it on only for the daemons you are actively investigating, then remove the
[otel]block when you are done — health checks and structured logs already cover everyday monitoring.