Skip to main content
Start with the public health checks, then use the Keyring request ID and protected logs to identify the failing boundary. Customers do not need to call Keyring’s authenticated application endpoints directly.

​
Verify the public path

Run these checks through the same HTTPS hostname, load balancer, and firewall path that Composio uses:
If the checks work from your network but not from Composio, review the public DNS, certificate, edge source allowlist, and Composio egress addresses.

​
Check Composio authentication

If Composio receives 401, compare these values first: A project ID beginning with pr_ is not a valid AUTH_AUDIENCE. Keyring authenticates the Composio organization; project connection is configured separately.

​
Common failures

Likely cause: a required environment variable is missing, the encryption configuration is invalid, production URLs are not HTTPS, KMS identity cannot initialize, or required auditing has no collector URL.Fix: compare the deployment against Runtime configuration and Encryption configuration. Startup logs name the invalid field without printing its secret value.
Likely cause: the asymmetric key is missing, disabled, unreachable, uses the wrong RSA OAEP algorithm, or the Keyring workload lacks public-key access.Fix: confirm the configured transfer-key version, provider permissions, and RSA OAEP SHA-256 properties.
Likely cause: the toolkit, destination, token operation, redirect, secret placement, key, or environment is denied by policy.Fix: use the request ID to find the warning event. Correct a toolkit or destination mismatch; do not broaden the provider allowlist before understanding the denial.
Likely cause: workload identity is missing, the exact key permission is absent, a key is disabled, or the configuration references an old key.Fix: verify the ECS task role, Cloud Run service identity, Kubernetes workload identity, or Vault auth role. Keep historical keys configured until every stored credential has been migrated.
Likely cause: AUDIT_DURABILITY=required is working as designed and your collector did not acknowledge the audit event.Fix: restore collector network, authentication, and ingestion health. Switch to best_effort only after an authorized owner accepts the loss of the audit gate.

​
Status codes in Keyring logs

A provider can return its own non-success status. Use the Keyring request ID and event source to distinguish a provider response from a Keyring denial.

​
Safe diagnostics

Collect only:
  • Keyring request ID and timestamp;
  • HTTP status and safe error tag;
  • deployment environment and release/image tag;
  • toolkit and provider hostname; and
  • relevant KMS key identifier, workload role, or audit collector status.
Never paste authorization headers, signed JWTs, sealed browser payloads, encrypted credential data, decrypted provider responses, environment dumps, or collector credentials into tickets or chat. After the issue is resolved, confirm that the corresponding customer audit event records the tool call or OAuth operation and its final outcome.