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 access tokens refreshed ahead of expiry, so an expiring token is not what interrupts a conversation. A grant the vendor revokes, or a sign-in the vendor invalidates, still stops the connector — that is a vendor decision StackJack cannot refresh past.
• 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

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:

1. 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).
2. 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.

StackJack retries some auto-disabled sign-in connections on its own

StackJack retries some auto-disabled sign-in connections on its own, for example after a vendor outage or a temporary refusal. It is worth knowing the limits so you can tell whether waiting is reasonable:

• Only sign-in connections qualify. These are the connectors configured by signing in rather than by pasting a key.
• Only StackJack's own automatic disable qualifies. A connection an administrator switched off is left alone.
• Only for seven days after the disable. Past that, only a person can bring it back.
• A bounded number of attempts, spread out. StackJack tries at most once every couple of hours and at most eight times in that window, which spans roughly the first half-day. It stops after that.
• A successful retry re-enables the connection. A failed one changes nothing and does not count as a new strike.

This recovers a temporary vendor refusal. It does not recover a grant that was genuinely revoked, a deleted account, or a rotated secret — those need the fix above. If the card is still Disabled the next morning, treat it as a real problem rather than waiting longer.

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.