Observability

Observability in Cessy starts from the event-sourced flow. When behavior is wrong, follow the path from command to event to projection to policy or integration.

What to observe

AreaSignals
Commandsrequest input, actor, permission decision, validation result, emitted events
Eventsstream, event type, payload, metadata, ordering
Projectionsrebuild status, output state, query filters, stale reads
Policiestrigger event, guard result, action, retries, failures
Adaptersrequest target, auth, response, timeout, retry
Webhookssender auth, payload, mapping, command result
Subscriptionscursor, delivery status, retries
Agentstool calls, channel posts, command execution, page refresh
Pagesprojection reads, command mutations, auth failures, BFF calls

Activity first

Use Activity to trace runtime behavior before inspecting low-level logs. It should show the business sequence and platform side effects in one place.

Error log

Use error logs when Activity points to a platform, policy, adapter, webhook, auth, or projection failure. Preserve correlation ids when escalating.

Agent-specific traces

For runtime agents, inspect tool calls and channel messages. For builder agents, inspect Design MCP tool calls, workspace changes, validation output, and promotion records.

Debugging sequence

  1. Confirm target tenant, app, and environment.
  2. Confirm the published model contains the expected command or projection.
  3. Execute or replay the smallest failing path.
  4. Inspect Activity.
  5. Check error logs and affected integrations.
  6. Fix the model, permission, projection, policy, or integration.
  7. Re-run the smoke test.