Skip to content

Flag Observability

The SDK batches lightweight telemetry to Bridge on a timer — never in the evaluation path, never over the live channel. Evaluating a flag a thousand times in a render loop produces in-memory counter bumps, not network traffic.

Two independent streams:

  • Eval events — coalesced per (identity, flag, value) per minute. Answers “how many users, evaluating to what, how often.”
  • Call sites — where in your code each flag is read, deduped per identity. Answers “this flag is read from 5 distinct places,” as a set, not a frequency. Fingerprints are opaque by default; in dev mode they resolve to file:line.

Both streams degrade gracefully: if the telemetry endpoint is unreachable, evaluations are never blocked or delayed.

The flag detail page gives full operational context in one place:

  • Live match count — how many users currently match, powered by eval events. If Bridge has user records (auth enabled), a reach estimate shows alongside it — they answer different questions, so both are shown when available. Standalone deployments see the live match count.
  • Eval volume & value distribution — verify a rollout is ramping or a release hit its target.
  • Where used in code — the call-site list.
  • Last evaluated / dead-flag badge — flags with no evals in the last N days are flagged for cleanup before they accumulate.
  • Audit history — every change, who, when, with a before/after diff. Sourced from the API mutations, so it’s authoritative.
  • Connected clients — a live count of SDK instances currently subscribed to updates, so you know your changes have an audience.

Destructive actions (delete, breaking rule changes) confirm with the current match count and call-site count — so you don’t ship a silent outage.

Your own evals appear in the admin UI with modest delay (telemetry flushes on a ~30-second cadence). The loop:

  1. Run your app and hit the code path that evaluates the flag.
  2. Open the flag in the admin — the Discovered badge confirms the key arrived; eval counters confirm reporting works.
  3. Check the call-site list — your new call site should appear once per location.

Eval-event telemetry and call-site reporting opt out independently:

  • Keep counters on while disabling code-structure fingerprints, or
  • Disable both entirely — flags keep working; you lose the observability surfaces.

Combined with the anonymous tracking modes (persistent / session / none), this covers GDPR-conservative deployments.