{
  "schemaVersion": "1.0",
  "title": "Twenty health, observability, and recovery",
  "description": "Use this runbook when a Twenty replica is unhealthy, not ready, losing its lease, holding an Action without trustworthy terminal evidence, or failing to publish a verified webhook event.",
  "canonical": "https://getaip.org/docs/connectors/twenty/operations/health-observability-and-recovery",
  "route": "/docs/connectors/twenty/operations/health-observability-and-recovery",
  "source": "docs/connectors/twenty/operations/health-observability-and-recovery.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/twenty/operations/health-observability-and-recovery.md",
    "txt": "/docs/download/connectors/twenty/operations/health-observability-and-recovery.txt",
    "json": "/docs/download/connectors/twenty/operations/health-observability-and-recovery.json",
    "pdf": "/docs/download/connectors/twenty/operations/health-observability-and-recovery.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Twenty health, observability, and recovery\ndescription: >-\n  Diagnose host, provider, lease, storage, Action, webhook, and event state and\n  recover without discarding durable identity\nkind: runbook\naudience: operator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: twenty\naliases:\n  - Twenty connector health\n  - Twenty connector observability\n  - Recover the Twenty connector\n---\n\n# Twenty health, observability, and recovery\n\nUse this runbook when a Twenty replica is unhealthy, not ready, losing its\nlease, holding an Action without trustworthy terminal evidence, or failing to\npublish a verified webhook event.\n\nPreserve PostgreSQL, provider, registry, Action, replay, event, and outbox\nevidence before changing the deployment. A green signal at one boundary does\nnot prove the others.\n\n## Start with the four boundaries\n\n| Boundary | Primary evidence | Healthy meaning | Excluded meaning |\n|---|---|---|---|\n| Host process | `GET /health` | Router responds with static AIP host identity | Storage, lease, or provider readiness |\n| Fleet replica | `GET /ready` | Not draining; lease, storage, and connector probe pass | Every Twenty operation works |\n| Provider Action | Durable Action, checkpoint, result, receipts, provider request ID | Evidence agrees on one terminal intent | Downstream automation completed |\n| Webhook event | Replay scope, local event, outbox batch, central event ID | One delivery is durably owned | Every provider event will arrive |\n\nCheck process and routing boundaries before tenant traffic. Investigate Action\nand webhook evidence by their original identities rather than submitting\nreplacement work.\n\n## Read host liveness\n\nThe host `/health` response is static:\n\n```json\n{\n  \"status\": \"ok\",\n  \"protocol\": \"AIP\",\n  \"version\": \"1.0\",\n  \"service\": \"aip-connector-host\"\n}\n```\n\nUse it only to determine whether the process and HTTP router respond. Failure\npoints first to process termination, listener binding, ingress, resource limits,\nor container state.\n\nDo not use `/health` as a provider, PostgreSQL, lease, credential, operation,\nwebhook, or artifact check. The generic image healthcheck probes this static\nroute.\n\n## Read routing readiness\n\nThe host `/ready` endpoint returns HTTP `200` only when all conditions are true:\n\n1. the replica is not draining;\n2. its registry lease remains valid;\n3. durable runtime storage is readable and writable;\n4. the Twenty connector health probe succeeds within its deadline.\n\nOtherwise it returns HTTP `503` with structured state:\n\n```json\n{\n  \"status\": \"not_ready\",\n  \"lease_valid\": false,\n  \"draining\": false,\n  \"runtime\": {\n    \"durability\": \"durable\",\n    \"ready\": true,\n    \"detail\": \"durable runtime storage is readable and writable\"\n  },\n  \"connector\": {\n    \"ready\": true,\n    \"detail\": \"Twenty authenticated workspace API is reachable\"\n  }\n}\n```\n\nThe response also includes the runtime recovery report. Use each field rather\nthan reducing all readiness loss to one provider alarm.\n\nRemove a not-ready replica from new assignments. Preserve existing Action and\nwebhook identities until durable state is reconciled.\n\n## Understand the provider health probe\n\nThe connector sends authenticated `GET /rest/open-api/core` to its fixed\norigin. A successful HTTP status reports ready with the detail shown above.\n\nThe probe verifies:\n\n- provider DNS and network path at that moment;\n- TLS and fixed origin routing;\n- current API token acceptance for the core OpenAPI route;\n- provider response status within the health timeout.\n\nIt does not decode the OpenAPI body or verify workspace data. It does not test\nrecord mutation, metadata permission, provider schema, idempotency, webhook\nregistration, event delivery, response-size handling, or the pinned provider\nrevision.\n\nA credential can pass the probe while lacking permission for another admitted\noperation. Diagnose the exact Action separately.\n\n## Monitor host metrics\n\nHost `/metrics` exposes eight Prometheus text metrics without labels:\n\n| Metric | Type | Interpretation |\n|---|---|---|\n| `aip_connector_host_ready` | Gauge | Cached conjunction of lease, storage, connector, and drain state |\n| `aip_connector_host_storage_ready` | Gauge | Cached durable runtime storage result |\n| `aip_connector_host_in_flight` | Gauge | Actions currently held by the host limiter |\n| `aip_connector_host_requests_total` | Counter | Native AIP requests observed |\n| `aip_connector_host_rejected_total` | Counter | Requests rejected before or during dispatch |\n| `aip_connector_host_heartbeat_failures_total` | Counter | Failed heartbeat or lease-recovery cycles |\n| `aip_connector_host_lease_recovery_attempts_total` | Counter | Re-registration attempts after lease expiry |\n| `aip_connector_host_lease_recoveries_total` | Counter | Successful lease recoveries |\n\nAdd instance, replica, tenant, region, zone, artifact, and deployment labels in\nthe scrape configuration rather than changing the metric names.\n\nAlert on readiness loss, storage loss, sustained in-flight saturation,\nrejection growth, heartbeat failures, and recovery attempts without matching\nrecoveries.\n\nThe reviewed Twenty host exposes no connector-specific metrics for provider\nstatus, webhook nonce count, local events, pending outbox batches, or central\nacknowledgements. Collect those through bounded durable-store diagnostics,\nstructured deployment telemetry, and exact event evidence.\n\n## Correlate durable evidence\n\nUse these identities for every investigation:\n\n- connector type, version, instance, replica, artifact, and configuration revision;\n- tenant, membership, external account, workspace, and credential revision;\n- AIP Action ID, capability, canonical input hash, and idempotency-key digest;\n- approval ID, decision ID, and policy hash for mutations;\n- execution checkpoint, terminal status, result, error, and receipts;\n- provider HTTP status and bounded request ID;\n- webhook ID, nonce digest, deterministic event ID, replay scope, and event time;\n- local event identity, outbox batch identity, and central delivery outcome.\n\nDo not log provider token, webhook secret, raw webhook payload, full\nidempotency key, or unredacted record and metadata bodies.\n\nThe connector exposes a bounded provider error allowlist. Absence of an\nunlisted provider field is expected and is not proof that the provider omitted\nit.\n\n## Recover a provider readiness failure\n\n1. remove the replica from new assignments;\n2. retain `/ready`, metric, lease, artifact, configuration, and credential state;\n3. verify fixed origin, DNS, network policy, TLS, and redirect behavior;\n4. verify token file ownership, current credential revision, and workspace binding without printing the token;\n5. check authenticated core OpenAPI status through the deployment's controlled path;\n6. compare provider maintenance and rate-limit evidence;\n7. repair the fixed dependency without changing tenant or instance identity;\n8. require `/ready` to return `200` before restoring route weight.\n\nDo not prove recovery with a mutation. Use the same bounded read or health path\nuntil routing readiness is restored.\n\n## Recover a runtime storage failure\n\nWhen `/ready` reports `runtime.ready: false`:\n\n1. stop new assignments and webhook registration changes;\n2. preserve host and PostgreSQL state before restart or failover;\n3. verify database endpoint, URL file, TLS, role, capacity, locks, and schema availability;\n4. inspect the structured runtime recovery report;\n5. preserve queued Action, idempotency, checkpoint, replay, event, and outbox identities;\n6. restore readable and writable durable storage without replacing logical IDs;\n7. require storage and connector readiness before reassignment.\n\nHost registration is blocked when durable recovery reports queued-Action or\ndelegation errors. Investigate those records instead of forcing the replica\nonline.\n\nDo not replace PostgreSQL with an empty database to clear a failure. That can\ndiscard idempotency, replay, event, and outbox ownership while external effects\nremain.\n\n## Recover an expired lease\n\nThe heartbeat loop probes connector and storage health before renewal. An\nexpired lease is re-registered only while both are ready.\n\nFor an ambiguous control-plane failure, the host retains one stable recovery\nrequest identity and payload for idempotent replay. Admission or configuration\nrejection clears that pending identity because no lease committed.\n\nIf lease recovery fails:\n\n1. keep the replica out of new assignments;\n2. compare attempt, recovery, and heartbeat-failure counters;\n3. verify control-plane endpoint, TLS, DID, and registry identity;\n4. check for a live conflicting replica or immutable identity mismatch;\n5. repair the control-plane boundary;\n6. observe one successful recovery and a valid lease in `/ready`.\n\nDo not start a second process with the same replica ID while the first may hold\na valid lease.\n\n## Recover an interrupted or uncertain Action\n\nRead the original Action, result, error, receipts, idempotency record, and\nprovider request identity before deciding.\n\n| Evidence | Response |\n|---|---|\n| Read failed temporarily | Retry the same read intent according to policy |\n| Mutation has no provider dispatch evidence | Classify the exact failure before deciding on a new intent |\n| Completed result and expected provider state agree | Retain the result and verification read |\n| Action is pending or approval-held | Continue the original lifecycle |\n| Mutation reports uncertain outcome | Inspect actual provider state; do not replace the Action or key |\n| Provider state proves intended effect | Record reconciliation evidence without replay |\n| Provider state proves no effect after bounded review | Create a new governed intent only under recovery policy |\n| State remains ambiguous | Escalate and preserve the mutation fence |\n\n`record.create`, `record.create_many`, and `record.update` advertise retry safety\nwith the original key. That contract does not authorize a new Action, new key,\nchanged body, or automatic retry after an unresolved outcome.\n\nThe other eleven mutations advertise unsafe retry. All mutation response or\npost-connection failures can require provider-state reconciliation.\n\nThe connector exposes no reconciliation operation. Use authorized bounded\nreads and external provider evidence while retaining the original AIP chain.\n\n## Recover webhook ingress\n\nClassify the public response first:\n\n| Response | Primary boundary |\n|---|---|\n| `400 webhook.missing_header` | Proxy or provider omitted an exact required header |\n| `401 webhook.authentication_failed` | HMAC, time, nonce, JSON, workspace, or payload validation |\n| `503 webhook.storage_unavailable` | Replay, event-log, or durable-outbox state |\n| `200 centrally_acknowledged` | Local acceptance and central acknowledgement completed |\n| `200 durably_queued` | Local outbox owns delivery; central acknowledgement is pending |\n\nFor repeated `401`, verify exact raw-body preservation, clock, secret revision,\nworkspace, registration, and nonce reuse without exposing secret or body.\n\nFor `503`, preserve replay scope, nonce admission state, event log, profile\nstate, database, and outbox before changing the host. Replay admission occurs\nbefore payload persistence, so the same nonce may already be fenced.\n\nDo not ask the provider to resend the same nonce after a late local failure.\nDetermine whether the deterministic event or durable batch exists and recover\nfrom the owned stage.\n\n## Recover central event publication\n\nA `durably_queued` response means the exact normalized batch exists in local\nprofile state or was already acknowledged. The background worker owns delivery.\n\n1. search local event log by deterministic event ID;\n2. locate the durable outbox batch derived from channel and event data;\n3. verify event endpoint, route authorization, TLS, central ingress, and host signing identity;\n4. inspect attempts, next attempt, lease owner, lease expiry, and bounded last error;\n5. restore central reachability without changing event or batch identity;\n6. confirm central observation of the same event ID;\n7. confirm the durable batch drains according to publisher policy.\n\nA crash after central acknowledgement but before local deletion can resend the\nsame event ID. Central event storage owns deduplication of that identity.\n\nDo not edit an event ID, create a new batch, or clear the outbox merely to make\nthe queue appear empty.\n\n## Drain and restore routing\n\nGraceful shutdown marks the replica draining, waits for in-flight work within\nthe configured deadline, stops the listener, and attempts an offline registry\ntransition.\n\nBefore stopping, preserve:\n\n- nonterminal and uncertain Action identities;\n- provider request and verification evidence;\n- replay and local event state;\n- pending durable event batches;\n- lease, heartbeat, metrics, and recovery state.\n\nAfter repair, require:\n\n- static host liveness and structured readiness;\n- authenticated provider health against the intended workspace;\n- readable and writable PostgreSQL with clean recovery report;\n- valid lease and exact replica identity;\n- stable metrics during an observation window;\n- reconciled uncertain Actions;\n- recovered webhook events and outbox batches;\n- a bounded qualification result for the affected behavior.\n\nRestore route weight gradually. Keep the previous artifact and database\nrecovery point available until the incident observation window closes.\n\n## Related documentation\n\n- [Deploy the Twenty connector](deployment.md)\n- [Twenty connector configuration](../reference/configuration.md)\n- [Twenty webhook security, replay, and events](../reference/webhook-security-replay-and-events.md)\n- [Errors and retry decisions](../../../reference/errors.md)\n- [Metrics reference](../../../reference/metrics.md)\n",
    "text": "Twenty health, observability, and recovery\n\nUse this runbook when a Twenty replica is unhealthy, not ready, losing its\nlease, holding an Action without trustworthy terminal evidence, or failing to\npublish a verified webhook event.\n\nPreserve PostgreSQL, provider, registry, Action, replay, event, and outbox\nevidence before changing the deployment. A green signal at one boundary does\nnot prove the others.\n\nStart with the four boundaries\n\n| Boundary | Primary evidence | Healthy meaning | Excluded meaning |\n\n| Host process | GET /health | Router responds with static AIP host identity | Storage, lease, or provider readiness |\n| Fleet replica | GET /ready | Not draining; lease, storage, and connector probe pass | Every Twenty operation works |\n| Provider Action | Durable Action, checkpoint, result, receipts, provider request ID | Evidence agrees on one terminal intent | Downstream automation completed |\n| Webhook event | Replay scope, local event, outbox batch, central event ID | One delivery is durably owned | Every provider event will arrive |\n\nCheck process and routing boundaries before tenant traffic. Investigate Action\nand webhook evidence by their original identities rather than submitting\nreplacement work.\n\nRead host liveness\n\nThe host /health response is static:\n\n{\n  \"status\": \"ok\",\n  \"protocol\": \"AIP\",\n  \"version\": \"1.0\",\n  \"service\": \"aip-connector-host\"\n}\n\nUse it only to determine whether the process and HTTP router respond. Failure\npoints first to process termination, listener binding, ingress, resource limits,\nor container state.\n\nDo not use /health as a provider, PostgreSQL, lease, credential, operation,\nwebhook, or artifact check. The generic image healthcheck probes this static\nroute.\n\nRead routing readiness\n\nThe host /ready endpoint returns HTTP 200 only when all conditions are true:\n1. the replica is not draining;\n2. its registry lease remains valid;\n3. durable runtime storage is readable and writable;\n4. the Twenty connector health probe succeeds within its deadline.\n\nOtherwise it returns HTTP 503 with structured state:\n\n{\n  \"status\": \"notready\",\n  \"leasevalid\": false,\n  \"draining\": false,\n  \"runtime\": {\n    \"durability\": \"durable\",\n    \"ready\": true,\n    \"detail\": \"durable runtime storage is readable and writable\"\n  },\n  \"connector\": {\n    \"ready\": true,\n    \"detail\": \"Twenty authenticated workspace API is reachable\"\n  }\n}\n\nThe response also includes the runtime recovery report. Use each field rather\nthan reducing all readiness loss to one provider alarm.\n\nRemove a not-ready replica from new assignments. Preserve existing Action and\nwebhook identities until durable state is reconciled.\n\nUnderstand the provider health probe\n\nThe connector sends authenticated GET /rest/open-api/core to its fixed\norigin. A successful HTTP status reports ready with the detail shown above.\n\nThe probe verifies:\n• provider DNS and network path at that moment;\n• TLS and fixed origin routing;\n• current API token acceptance for the core OpenAPI route;\n• provider response status within the health timeout.\n\nIt does not decode the OpenAPI body or verify workspace data. It does not test\nrecord mutation, metadata permission, provider schema, idempotency, webhook\nregistration, event delivery, response-size handling, or the pinned provider\nrevision.\n\nA credential can pass the probe while lacking permission for another admitted\noperation. Diagnose the exact Action separately.\n\nMonitor host metrics\n\nHost /metrics exposes eight Prometheus text metrics without labels:\n\n| Metric | Type | Interpretation |\n\n| aipconnectorhostready | Gauge | Cached conjunction of lease, storage, connector, and drain state |\n| aipconnectorhoststorageready | Gauge | Cached durable runtime storage result |\n| aipconnectorhostinflight | Gauge | Actions currently held by the host limiter |\n| aipconnectorhostrequeststotal | Counter | Native AIP requests observed |\n| aipconnectorhostrejectedtotal | Counter | Requests rejected before or during dispatch |\n| aipconnectorhostheartbeatfailurestotal | Counter | Failed heartbeat or lease-recovery cycles |\n| aipconnectorhostleaserecoveryattemptstotal | Counter | Re-registration attempts after lease expiry |\n| aipconnectorhostleaserecoveriestotal | Counter | Successful lease recoveries |\n\nAdd instance, replica, tenant, region, zone, artifact, and deployment labels in\nthe scrape configuration rather than changing the metric names.\n\nAlert on readiness loss, storage loss, sustained in-flight saturation,\nrejection growth, heartbeat failures, and recovery attempts without matching\nrecoveries.\n\nThe reviewed Twenty host exposes no connector-specific metrics for provider\nstatus, webhook nonce count, local events, pending outbox batches, or central\nacknowledgements. Collect those through bounded durable-store diagnostics,\nstructured deployment telemetry, and exact event evidence.\n\nCorrelate durable evidence\n\nUse these identities for every investigation:\n• connector type, version, instance, replica, artifact, and configuration revision;\n• tenant, membership, external account, workspace, and credential revision;\n• AIP Action ID, capability, canonical input hash, and idempotency-key digest;\n• approval ID, decision ID, and policy hash for mutations;\n• execution checkpoint, terminal status, result, error, and receipts;\n• provider HTTP status and bounded request ID;\n• webhook ID, nonce digest, deterministic event ID, replay scope, and event time;\n• local event identity, outbox batch identity, and central delivery outcome.\n\nDo not log provider token, webhook secret, raw webhook payload, full\nidempotency key, or unredacted record and metadata bodies.\n\nThe connector exposes a bounded provider error allowlist. Absence of an\nunlisted provider field is expected and is not proof that the provider omitted\nit.\n\nRecover a provider readiness failure\n1. remove the replica from new assignments;\n2. retain /ready, metric, lease, artifact, configuration, and credential state;\n3. verify fixed origin, DNS, network policy, TLS, and redirect behavior;\n4. verify token file ownership, current credential revision, and workspace binding without printing the token;\n5. check authenticated core OpenAPI status through the deployment's controlled path;\n6. compare provider maintenance and rate-limit evidence;\n7. repair the fixed dependency without changing tenant or instance identity;\n8. require /ready to return 200 before restoring route weight.\n\nDo not prove recovery with a mutation. Use the same bounded read or health path\nuntil routing readiness is restored.\n\nRecover a runtime storage failure\n\nWhen /ready reports runtime.ready: false:\n1. stop new assignments and webhook registration changes;\n2. preserve host and PostgreSQL state before restart or failover;\n3. verify database endpoint, URL file, TLS, role, capacity, locks, and schema availability;\n4. inspect the structured runtime recovery report;\n5. preserve queued Action, idempotency, checkpoint, replay, event, and outbox identities;\n6. restore readable and writable durable storage without replacing logical IDs;\n7. require storage and connector readiness before reassignment.\n\nHost registration is blocked when durable recovery reports queued-Action or\ndelegation errors. Investigate those records instead of forcing the replica\nonline.\n\nDo not replace PostgreSQL with an empty database to clear a failure. That can\ndiscard idempotency, replay, event, and outbox ownership while external effects\nremain.\n\nRecover an expired lease\n\nThe heartbeat loop probes connector and storage health before renewal. An\nexpired lease is re-registered only while both are ready.\n\nFor an ambiguous control-plane failure, the host retains one stable recovery\nrequest identity and payload for idempotent replay. Admission or configuration\nrejection clears that pending identity because no lease committed.\n\nIf lease recovery fails:\n1. keep the replica out of new assignments;\n2. compare attempt, recovery, and heartbeat-failure counters;\n3. verify control-plane endpoint, TLS, DID, and registry identity;\n4. check for a live conflicting replica or immutable identity mismatch;\n5. repair the control-plane boundary;\n6. observe one successful recovery and a valid lease in /ready.\n\nDo not start a second process with the same replica ID while the first may hold\na valid lease.\n\nRecover an interrupted or uncertain Action\n\nRead the original Action, result, error, receipts, idempotency record, and\nprovider request identity before deciding.\n\n| Evidence | Response |\n\n| Read failed temporarily | Retry the same read intent according to policy |\n| Mutation has no provider dispatch evidence | Classify the exact failure before deciding on a new intent |\n| Completed result and expected provider state agree | Retain the result and verification read |\n| Action is pending or approval-held | Continue the original lifecycle |\n| Mutation reports uncertain outcome | Inspect actual provider state; do not replace the Action or key |\n| Provider state proves intended effect | Record reconciliation evidence without replay |\n| Provider state proves no effect after bounded review | Create a new governed intent only under recovery policy |\n| State remains ambiguous | Escalate and preserve the mutation fence |\n\nrecord.create, record.createmany, and record.update advertise retry safety\nwith the original key. That contract does not authorize a new Action, new key,\nchanged body, or automatic retry after an unresolved outcome.\n\nThe other eleven mutations advertise unsafe retry. All mutation response or\npost-connection failures can require provider-state reconciliation.\n\nThe connector exposes no reconciliation operation. Use authorized bounded\nreads and external provider evidence while retaining the original AIP chain.\n\nRecover webhook ingress\n\nClassify the public response first:\n\n| Response | Primary boundary |\n\n| 400 webhook.missingheader | Proxy or provider omitted an exact required header |\n| 401 webhook.authenticationfailed | HMAC, time, nonce, JSON, workspace, or payload validation |\n| 503 webhook.storageunavailable | Replay, event-log, or durable-outbox state |\n| 200 centrallyacknowledged | Local acceptance and central acknowledgement completed |\n| 200 durablyqueued | Local outbox owns delivery; central acknowledgement is pending |\n\nFor repeated 401, verify exact raw-body preservation, clock, secret revision,\nworkspace, registration, and nonce reuse without exposing secret or body.\n\nFor 503, preserve replay scope, nonce admission state, event log, profile\nstate, database, and outbox before changing the host. Replay admission occurs\nbefore payload persistence, so the same nonce may already be fenced.\n\nDo not ask the provider to resend the same nonce after a late local failure.\nDetermine whether the deterministic event or durable batch exists and recover\nfrom the owned stage.\n\nRecover central event publication\n\nA durablyqueued response means the exact normalized batch exists in local\nprofile state or was already acknowledged. The background worker owns delivery.\n1. search local event log by deterministic event ID;\n2. locate the durable outbox batch derived from channel and event data;\n3. verify event endpoint, route authorization, TLS, central ingress, and host signing identity;\n4. inspect attempts, next attempt, lease owner, lease expiry, and bounded last error;\n5. restore central reachability without changing event or batch identity;\n6. confirm central observation of the same event ID;\n7. confirm the durable batch drains according to publisher policy.\n\nA crash after central acknowledgement but before local deletion can resend the\nsame event ID. Central event storage owns deduplication of that identity.\n\nDo not edit an event ID, create a new batch, or clear the outbox merely to make\nthe queue appear empty.\n\nDrain and restore routing\n\nGraceful shutdown marks the replica draining, waits for in-flight work within\nthe configured deadline, stops the listener, and attempts an offline registry\ntransition.\n\nBefore stopping, preserve:\n• nonterminal and uncertain Action identities;\n• provider request and verification evidence;\n• replay and local event state;\n• pending durable event batches;\n• lease, heartbeat, metrics, and recovery state.\n\nAfter repair, require:\n• static host liveness and structured readiness;\n• authenticated provider health against the intended workspace;\n• readable and writable PostgreSQL with clean recovery report;\n• valid lease and exact replica identity;\n• stable metrics during an observation window;\n• reconciled uncertain Actions;\n• recovered webhook events and outbox batches;\n• a bounded qualification result for the affected behavior.\n\nRestore route weight gradually. Keep the previous artifact and database\nrecovery point available until the incident observation window closes.\n\nRelated documentation\n• Deploy the Twenty connector (deployment.md)\n• Twenty connector configuration (../reference/configuration.md)\n• Twenty webhook security, replay, and events (../reference/webhook-security-replay-and-events.md)\n• Errors and retry decisions (../../../reference/errors.md)\n• Metrics reference (../../../reference/metrics.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "4561c6f686626443fa00e215b70be011fc3834cd01e01c5cfdbe1ad8b5cf2c3d"
  }
}