Skip to main content

​
Health tab

Open Settings → Integrations → Health to review the integration execution plane. The Health tab summarizes:
  • Enabled and unhealthy connections
  • Connector action success and failure counts
  • Recent execution latency and errors
  • Credential health and rotation state
  • Installed catalog size and connector maturity
  • Jira outbox and webhook status counts for the last 24 hours
  • Jira policy version, sync health, and recent recoverable failures
Select Manage on a Connections row, then Test connection, to run the connector’s declared health action. Testing uses the same host allowlist, timeout, response limit, tenant isolation, and redaction controls as production execution.

​
Jira recovery

Jira outbound automation is recorded in a durable tenant-scoped outbox. Retry now makes an eligible failed event immediately available without changing its remaining attempt budget. Replay moves a dead-letter event back to pending and grants the displayed additional attempts. Both actions preserve the event’s original policy snapshot, payload, correlation context, and idempotency key, and both write an immutable unified audit record. Confirm the mapping or provider problem is resolved before recovery. Recovery controls are available only to users with existing integration-management permission, and event identifiers are resolved inside the active organization. Jira webhook processing uses an expiring ownership lease. Release lease is available only when a PROCESSING receipt is stale. Releasing it marks the expired claim failed so the existing queue retry or Jira redelivery can claim the receipt. It does not republish or reconstruct the webhook: raw inbound payloads are intentionally not persisted. Use Jira’s delivery log to redeliver a failed webhook when the worker queue no longer has the original message.

​
Connector maturity

Catalog entries can be certified, supported, community, private, or deprecated. Maturity is version-specific. Casebender pins the connector version when creating a connection.

​
Troubleshooting

  1. Confirm both workflow-processor and connector-worker are healthy.
  2. Confirm they use the same Redis action and result queue names.
  3. Check that the connection is enabled and visible to the workflow’s organization.
  4. Verify that a live credential is bound and that its host allowlist covers the configured base URL.
  5. Review the connector worker error and circuit-breaker state.
  6. Rotate an expired credential, then retest the connection.
  7. For Jira, inspect failed/dead-letter automation and failed, rejected, or stale webhook receipts. Resolve the cause before using recovery.
Connector responses are bounded and secret fields are redacted before outputs are persisted. Use vendor-side request identifiers for deeper investigation; do not enable raw secret or response-body logging. For emergency rollback, disable the connection to stop new workflow and automation use. Disable individual Jira policy controls when only one event class must stop. Restoring previous mappings publishes a new policy version; historical outbox events remain immutable.