Binions does not ship a catalogue of numbered error codes — it reports descriptive, typed error messages instead. When something goes wrong you will see a named error in a log line, a health-check response, or a command’s output that tells you in plain language what failed. This page is a reference to the common ones, what each means, and which page fixes it.
No numeric code list. There is no “error E1234” table to look up. If you are searching for a specific code number, you won’t find one — instead, match the message text or behaviour below to its meaning.
Most errors reach you in one of three places. Knowing where you saw the message usually tells you which group it belongs to:
200 or 503 from a daemon’s readiness endpoint, rolled up by binions-cliconsole status.binions-cliconsole status # readiness of every daemon, in one table
journalctl -u binions-<name> -n 100 --no-pager # the actual error text for one daemonEach row pairs the error you’ll see with its plain-English meaning and where to fix it.
| Group | What you see | What it means & where to fix |
|---|---|---|
| Health / readiness | 200 OK | The daemon is live and ready — its dependencies are reachable and fresh. Nothing to do. |
| Health / readiness | 503 (not ready) | A dependency (usually its Redis) isn’t fresh yet. See Database & Redis problems. |
| Boot / config | Configuration error | A malformed application.toml stopped the daemon at boot. Fix the file and restart — see Daemon won’t start. |
| Boot / config | Redis connection error | The daemon couldn’t reach its Redis; the message names the URL that failed. Start that Redis — see Database & Redis problems. |
| Boot / config | Health-port bind error | The loopback health port is already in use, so the daemon couldn’t bind it. See Daemon won’t start. |
| Licence | Missing licence file | No licence is present for this daemon. Install via the command from the customer portal so the file is created. See License & activation problems. |
| Licence | Fingerprint mismatch | The licence is bound to a different host (after moving, cloning, or reinstalling). Release the token and redeem a fresh one. See License & activation problems. |
| Licence | Revoked / invalidated token | The token was released or revoked and is on the revocation list. Redeem a new one, or contact support. See License & activation problems. |
| Licence | Offline grace expired | The host stayed offline past the re-verification grace window. Reconnect it. See License & activation problems. |
| Event / payload | Payload-decode error | An event didn’t match the expected shape or version, so it couldn’t be decoded. |
| Event / payload | Schema-validation error | The event was decoded but failed validation — e.g. a missing field, an invalid event type, or a missing target service. |
| Playbook vocabulary | Unknown daemon / unknown operation | A playbook step names a daemon or operation that doesn’t exist. See Playbook debugging. |
| Playbook vocabulary | Operation deferred | The operation is in the vocabulary but not yet implemented. See Playbook debugging. |
| Upgrade gate | Gate exits non-zero | The major-version gate refused the upgrade and printed how to stay on your major version or buy the upgrade. |
For every event a daemon receives, the log records how it was dispatched. These are normal status words, not failures — but knowing them helps you read a run:
| Handled | A handler processed the event successfully. This is the healthy case. |
| Unhandled | No handler is subscribed to that event type — usually a typo or an unsubscribed type. The event is acknowledged and skipped. |
| Duplicate | The event was already processed; idempotency caught it and it was skipped safely. No work is done twice. |
Follow one workflow. Every event in a single run shares one
correlation_id. Grep the logs for it to see exactly where a chain of events becameUnhandledor stopped — that’s usually where the real fault is.