Troubleshooting

An integration shows "disabled"

Its required configuration is missing. Open it and fill in what is blank. Nothing blocks the app from starting because of a disabled integration.

An integration shows "degraded"

It started and then failed. The error text is on the card, and it is almost always one of:

• Wrong or expired credential. Re-enter it. Saving an enabled config tests it first, so a bad value cannot be stored.
• Unreachable from this machine. Production is behind a VPN and you are not on it, or the host is only routable from inside a cluster. Triagic runs locally; it needs the same network access you would need.
• TLS. An https:// endpoint with a private CA, a self-signed certificate, or a bare-IP URL. Give the CA bundle path, or turn off certificate verification for that integration — traffic stays encrypted either way, the certificate just is not checked.

Hit Restart on the card after fixing it.

cannot decrypt stored secrets

The local encryption key changed or was lost — usually a wiped data directory or a restored-from-backup machine. Stored secrets are unrecoverable.

Re-enter the affected integrations' credentials. Organization-shared integrations will re-sync from the portal on the next pull without you doing anything.

Saving a playbook or integration is refused

Your install is centrally managed. Playbooks, shared integrations, AI providers and organization settings are edited in the web portal, and the local refusal is deliberate — accepting the edit would mean losing it on the next sync.

A change made in the portal has not appeared

Sync is a poll, roughly every 15 minutes. Refresh in the app to pull immediately. If it still has not landed, work through the checklist in How configuration reaches the desktop.

The agent says it could not determine a root cause

Read the tool chips before assuming the model failed. The two common causes:

The evidence is outside the playbook's allowlist. The agent never saw the system holding the answer. Re-run the ticket under a broader playbook — or none — to confirm.

The evidence genuinely is not in any connected system. That is a real answer, and a better one than a confident guess.

Investigations stopped running

Check for a spend cap. Over-cap organizations get deferred background triage and a plain refusal on the Console with the cap and month-to-date spend in the message. An admin raises or removes the cap in the portal.

Nothing is being triaged at all

Ticket ingest is a HubSpot webhook plus a two-minute poller. If neither is delivering, nothing arrives to triage. Confirm tickets are appearing in the inbox at all — if they are not, the problem is ingest, not the agent.

Sign-in fails after it used to work

Your account may have been disabled in the portal. The cloud is re-checked on every authenticated call, so a disabled member fails in real time rather than at the next sync. Ask your admin.

Investigations are slow or expensive

• Narrow the playbook's data sources. Fewer systems, fewer iterations.
• Sharpen triage instructions. "Check payout_configs first, then the payout event log" beats "investigate payouts".
• Check the per-task split on Usage. Classification running on every ticket adds up; embeddings are cheap but constant.
• Check p95 latency per model on Usage — one badly-performing deployment can make everything feel broken.