{"slug":"operations/42-observability","title":"Observability","section":"operations","sectionLabel":"Operations","status":"unclassified","type":"document","path":"operations/42-observability.mdx","bytes":2700,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nObservability in IntegrateWise is built around three behaviors: trace execution, measure health, and preserve accountability.\n\nFor canonical runtime and operations context, see:\n\n- `docs/spec/INTEGRATEWISE_CANONICAL_SPEC_v1.0.md`\n- `docs/ops/RUNTIME_TOPOLOGY.md`\n- `docs/internal/operations/DEPLOYMENT_RUNBOOK.md`\n\n## Correlation and tracing\n\nEvery execution thread should carry a unique correlation identifier from the edge boundary. This identifier should be injected into internal messages, async event steps, and adapter payloads.\n\nIntegration partners should:\n\n- preserve correlation identifiers in outbound payloads where supported\n- log them alongside handler and transport metadata\n- include them in outcome and webhook payloads when available\n\n## Provider health\n\nProvider health states are exposed through registry telemetry. Health is evaluated along:\n\n- latency\n- error rate\n- saturation\n\nRolling windows and threshold rules are tenant-configurable. When health degrades:\n\n- registry shifts provider state to degraded\n- breaker logic may be tripped\n- Workbench displays explicit warnings\n- capability availability changes are reflected in the Capability Fabric surface\n\n## Execution telemetry\n\nHermes reports:\n\n- queued state\n- executing state\n- provider confirmation\n- timeout events\n- failure classifications\n- outcome events\n\nPartners should not infer success from absence of failure. Always check provider confirmation and promotion outcome before treating an action as canonical.\n\n## Audit expectations\n\nEvery consequential action should emit audit events that preserve:\n\n- actor\n- authority scope\n- policy validation result\n- affected context\n- exact provider operations\n- execution-plan version\n- approval record\n- provider outcome\n- synchronization result\n\nAudit logs are not debugging logs. They are accountability records.\n\n## Alerting and incident signals\n\nOperators should monitor:\n\n- provider error rates and breaker state changes\n- governance denial or approval latency\n- approved proposal execution failure rates\n- sync conflict volume\n- sync lag beyond configured policy windows\n- cache staleness for critical projections\n\nToy alerts increase incident noise. Target alerts that indicate material risk, user impact, time sensitivity, or system integrity issues.\n\n## Partner incident support\n\nWhen a partner integration causes incidents:\n\n- provide correlation IDs, approval tokens, proposal IDs, and execution-plan versions\n- preserve raw payloads and adapter responses within retention windows\n- do not alter logs after incident time without timestamped, documented, governed changes\n- notify the customer-facing support path through established channels\n"}