Octri

Monitoring

Setup

Monitoring is a toggle. The two steps after it are what people miss.

  1. Turn it on

    Open your project's Monitoring tab and enable it. Nothing to install, no agent to deploy, no instrumentation to write.

  2. Rebuild your SDKs

    The telemetry connection is compiled into the client when it's generated. Rebuild and publish, then make sure your users are on the new version.

  3. Upload symbols from CI

    Production builds are minified or compiled, so raw stack traces are unreadable. See Readable stack traces.

Why the rebuild matters

Enabling monitoring does nothing to already-published SDKs

The connection is baked in at build time. An SDK built before you enabled monitoring has no telemetry in it and never will, however long you wait.

Enable, rebuild, publish, and confirm your app is running the new version. Until then the Monitoring tab stays empty and everything looks broken.

The environment id

Enabling monitoring scopes your data to an environment id, which isolates your project's telemetry from everyone else's. You never set it by hand.

You do need it in one place: uploading symbols from CI. The Monitoring tab shows it alongside your ingest token.

bash
octri-monitoring sourcemaps upload ./dist \
  --environment "$MONITORING_ENVIRONMENT"

Checking it works

Make a request through a rebuilt SDK and watch the Logs tab. Events stream in live, so if nothing appears within a few seconds the client isn't reporting.

What's kept

Raw events are kept for 30 days. Charts keep working past that: they read hourly rollups, so a 90-day trend still renders even though you can no longer open an individual event from three months ago.

Your plan includes a monitoring storage allowance. Usage against it is shown in the dashboard, and events are counted as they arrive.