An integration that stops working is almost always a credentials, allow-list, or network problem — not a fault in Binions itself. Each integration lives inside one daemon, so the fastest route to the cause is that daemon’s logs and its Fact.*.Failed events. This page walks through the failures you’re most likely to see, integration by integration, with the cause and the fix for each.
Where to look first. Find the daemon that owns the integration, then read its recent logs. A failed call is recorded as a
Fact.<Domain>.Failedevent with the reason attached, so you rarely have to guess.
binions-cliconsole status # which daemon is DEGRADED or DOWN
journalctl -u binions-<name> -n 100 --no-pager # that daemon's recent logs and errorsSymptom: messages aren’t sent or received, and the logs show a connection or authentication failure to your IMAP, MQTT, or AMQP provider.
Symptom: an AI step fails immediately, or returns an authentication error.
classify, extract, and inject are implemented today. Operations such as generate or embed are not available yet, so a playbook that calls them will not run.Symptom: an outbound webhook or API call never reaches its destination and is reported as blocked.
webhook.send action, so the same allow-list governs both.webhook.send can also call gRPC services by setting protocol: grpc, which uses server reflection to discover the method. If the call fails, confirm the target host is on the allow-list and that the server exposes reflection.protocol: ssh, webhook.send runs a remote command over SSH. These calls are governed by a separate SSH allow-list, so a blocked command usually means the host isn’t listed there yet.This is a safety feature. The deny-by-default allow-list stops a misconfigured or hostile playbook from reaching internal services. Add only the destinations you intend to call.
Symptom: a file upload or download fails, or can’t find its destination.
Symptom: reads or writes to a PLC fail, time out, or are rejected.
open and pauses further attempts until the connection recovers. Confirm the PLC is powered, on the network, and reachable from the host.The reason is named in the modbus_connection_failures_total{reason} metric — the reason label is one of circuit_breaker_open, rate_limited, read_error, or write_error, which tells you which of the above you’re hitting.
Whatever the integration, the same three checks resolve the large majority of failures. Work through them in order, then re-run the workflow:
Tip. Once you’ve fixed the credential, allow-list entry, or network route, re-run the step and watch the daemon’s log for the matching
Fact.<Domain>.Succeededevent to confirm it’s healthy again.