Connector Health & Auto-Disable
Credentials break — vendor keys get rotated, OAuth grants get revoked, API users get deactivated. StackJack watches your connectors continuously so a broken credential is caught in the background, not discovered mid-conversation with your AI assistant.
How StackJack keeps connections alive
StackJack continuously re-checks every configured connector in the background:
- OAuth-based connectors get their tokens refreshed automatically so they never expire mid-use.
- All other connectors have their stored credentials re-validated against the vendor API if they haven't been checked recently.
You don't have to do anything for this — it's automatic from the moment a connector is saved, and you never manage tokens yourself.
Health states on the connector card
| Badge | Meaning | What you can do |
|---|---|---|
| Valid | The last check succeeded. | Nothing — you're healthy. |
| Invalid | The last check failed, but the connector is still enabled and being retried. The card shows a warning with the error. | Click Re-test to check again immediately, or Update to fix the credentials. |
| Disabled | The credential failed repeatedly and StackJack switched it off. Tool calls for this connector stop. | Fix the underlying problem, then Re-enable (see below). |
A Disabled badge has a keyboard-accessible "Why?" tooltip with the specific reason; Invalid and Disabled cards also show the full explanation in an alert directly on the card.
Auto-disable: the three-strike rule
A credential is automatically disabled after 3 consecutive definitive failures (transient hiccups like vendor outages or rate-limiting never count — see Validation at Save). When that happens:
- The card flips to Disabled with the reason and the time it was disabled.
- All tool calls for that connector stop for the affected credential until it's re-enabled.
- The tenant owner receives an email describing what broke, in plain language, with a recommended action. If the broken credential belongs to a specific team member (a per-user connection), the email says whose.
- The affected team member also gets an email — but only when re-authorizing themselves is actually the fix (for example, their personal OAuth grant was revoked). If the fix requires an administrator (for example, the shared app secret was rotated), the member is not bothered.
Recovering a disabled connector
On the disabled card you'll see the error details plus two buttons:
- Update Credentials — opens the configure dialog so you can enter corrected values. Use this first if the credentials themselves are wrong (rotated key, deleted API user).
- Re-enable — asks StackJack to validate against the vendor first and only then re-enable:
- If the vendor still rejects the credentials, re-enable fails with the vendor's (sanitized) response shown — fix the credentials and try again.
- If the vendor can't be reached at that moment (a transient problem), the connector is re-enabled anyway and marked "validation deferred" — the background checker will confirm it shortly.
For cards that are Invalid but not yet disabled, the Re-test button runs an immediate validation so you don't have to wait for the next background pass.
What the error messages look like
StackJack translates raw vendor errors into a "What this means" explanation and a "Recommended action" for each connector, and shows the vendor's own response in a collapsible detail (with any sensitive values redacted). The same guidance appears in the notification emails, so whoever reads the alert can act on it without logging in first.