Skip to main content
An integration connects one of your systems to OpenCluster. Each one is read-only or inbound-only: OpenCluster receives your alerts and reads your systems for evidence, and never writes to any of them.

What each integration gives you

You can connect several integrations of one type — two workspaces, two clusters — each as its own integration with its own name and credential.

The lifecycle

Every integration follows the same path: create → verify → operate → disable → delete.
  • Create checks the configuration and, for credential-bearing types, proves the credential against the vendor before anything is stored. A credential the vendor refuses is never saved.
  • Verify re-checks the integration on demand, live. Its status is observed, never declared — the note under it says exactly what was established, in plain words.
  • Disable stops the integration (deliveries are refused, investigations skip it) but keeps the record, its verification history and its credential. Re-enabling restores it as it was.
  • Delete is refused while anything depends on the integration — signals, incidents or investigation records. Disable is the retirement path; the record of what a source produced survives.

Statuses

Degraded is not broken: a Slack workspace connected with a bot token, for example, is degraded only because message search needs a user token — everything else works.

Capabilities follow the verified reality

What an investigation may read through an integration is derived from what its credential was actually granted, checked at verification. A capability the credential cannot support is simply absent from investigations — never offered and then failing. That is why verifying after changing scopes or permissions matters: it is how OpenCluster learns what changed.

Who can do what

Credentials

Webhook secrets are minted by OpenCluster, shown once, and stored only as digests. Pasted credentials (a Slack token) are verified live before storage, encrypted at rest, and never shown again — reads render only a fingerprint. The GitHub App credential stays with whoever operates the deployment and is never stored per integration. The full behavior is on Credential handling.