Platform Telemetry

Bridge v3 reports session activity and cluster health to your Britive tenant, so the tenant’s Session History and Bridge pages show what each deployment is doing. This page lists what is sent, when it is sent, and the settings that control it.

What is sent

Bridge sends three kinds of event, outbound over HTTPS, from the single or orchestrator role only.

Event	When	What it carries
`bridge.session.started`	A recorded session is established.	The session ID, protocol, access mode (native or browser), the Bridge username, the target (host and port, HTTP scope, or Kubernetes cluster and namespace), the client IP, and whether recording was requested.
`bridge.session.ended`	The session ends.	The same identity, plus the end reason, the duration, the recording state, and a review link into Bridge.
`bridge.cluster.snapshot`	Every five minutes, and when state changes.	The running Bridge version, the active-session count and totals by protocol, worker counts by role, the license state, and the configuration the deployment runs with: which protocols and login methods are enabled, and the recording and transport settings.

The snapshot describes configuration, never secrets. No credentials, target hostnames, or recording content leave the deployment. Session events carry the username and target so the platform can show who connected where. An HTTP checkout with more than 64 approved patterns reports the first 64 and a flag that the scope was cut short.

Telemetry is separate from Bridge’s own activity index and recordings. Those stay local whether telemetry is on or off. A platform outage never blocks a session: events wait in PostgreSQL and Bridge retries them.

When it is active

Telemetry authenticates to the tenant with the same credential as the bundled Britive Broker. On the single or orchestrator role, set BRITIVE_BROKER_AUTH_TOKEN and the tenant, through server.auth.britive.tenant or BRITIVE_BROKER_TENANT_SUBDOMAIN. Session and proxy workers report through PostgreSQL and need no platform credential.

Without a broker token, Bridge collects nothing and sends nothing. The tenant must also accept telemetry. Until it does, events stay queued and the Admin console shows the delivery error.

Settings

Both settings live under server.telemetry. As with every setting, the environment variable is the path in upper case with BRIDGE_ in front.

Setting	Environment variable	Default	Description
`server.telemetry.disabled`	`BRIDGE_SERVER_TELEMETRY_DISABLED`	`false`	`true` stops collection and delivery and deletes any queued events when the publisher starts. Set it back to `false` and restart to collect again. Events from the disabled period are not replayed.
`server.telemetry.review_base_url`	`BRIDGE_SERVER_TELEMETRY_REVIEW_BASE_URL`	`""`	Bridge’s public HTTPS origin, for example `https://bridge.example.com`, with no path, query, or credentials. Session-end events use it to build the review link. While it is empty or invalid, session-end events wait and the Admin console reports the error. Sessions are unaffected.

bridge.yaml

server:
  telemetry:
    disabled: false
    review_base_url: https://bridge.example.com

Where the settings go, by deployment:

Single server. In bridge.yaml, or as environment variables on the bridge service in the Compose file.
AWS ECS. The template sets BRIDGE_SERVER_TELEMETRY_REVIEW_BASE_URL from the BridgeUrl parameter on every task. To disable telemetry, add server.telemetry.disabled: true to a config file supplied through BridgeConfigSecretArn.
Kubernetes. Under config.extraConfig.server.telemetry in your Helm values. The shared configuration carries it to every role.

The configuration file is the only control. There is no switch in the Admin console, and a change takes effect when the single or orchestrator role restarts.

Check delivery

Open Telemetry in the Admin console, or call GET /api/admin/telemetry with an administrator session, to see the pending session-event count, whether a cluster report is waiting, the last acknowledgement from the platform, and the deployment ID. Each error has a plain-language explanation next to it. The two you are most likely to see:

Review origin missing or invalid. Set server.telemetry.review_base_url. Session-end events wait until it is valid.
Credential or binding rejected. The tenant refused the broker token or its pool assignment. Check the token and its platform assignment. Bridge keeps retrying.

Repair the review origin without a restart

If the public URL changed, or was empty at first start, store it directly:

terminal

britive-bridge --config /etc/britive-bridge/config.yaml --set-review-origin https://bridge.example.com

The command applies migrations, stores the origin, and exits without starting a listener. Session-end events that were waiting for an origin are sent with the new one. Events already delivered are unchanged.

Last updated on November 3, 2026

Activity Search & SIEM Export