Skip to main content

Sentry

Sentry readiness should distinguish repository configuration, live event visibility, event ingest, and production readiness.

Logs must be scrubbed. Send only controlled redacted logs for verification; never include API keys, cookies, bearer tokens, or raw memory payloads.

Production project​

UnifiedMemory uses one Sentry project for new production telemetry:

SENTRY_ORG=indiana-tech
SENTRY_PROJECT=unified-memory
SENTRY_RELEASE=unified-memory@GIT_SHA

The single project receives events from:

  • Cloudflare OpenNext web runtime;
  • FastAPI origin;
  • Cloudflare Worker edge gateway;
  • scheduled/queue/proof jobs that emit controlled check-ins.

Every event should include service, runtime, route_family, memory_surface, trace_id when available, environment, and release.

Capture policy​

Maximum capture is enabled only with UnifiedMemory-safe redaction:

  • errors, traces, logs, source maps, releases, deploys, replay, profiling, and cron check-ins are allowed;
  • browser replay stays masked with all text, inputs, and media blocked;
  • AI spans may record provider, model, route, token count, latency, and status only;
  • prompts, memory bodies, profile facts, transcript text, connector payloads, uploaded document text, cookies, bearer tokens, API keys, and session handles are forbidden.

Operator checks​

Use Settings / Ops to inspect Sentry status. The important states are:

  • repo_ok: SDKs, scrubbers, release config, and proof tooling are present;
  • project_visible: the configured token can see unified-memory;
  • release_visible: the current deploy release exists in Sentry;
  • event_ingest_ok, log_ingest_ok, and cron_monitor_ok: controlled admin proof events landed;
  • production_ready: all required proof gates passed.

Dry-runs are useful for repository checks, but they must never claim production readiness.