Setup

Monitoring requires two opt-ins: the project owner enables it, then each developer using a rebuilt SDK enables reporting in their application.

Turn it on

Open your project's Monitoring tab and enable it. This adds a project-scoped reporting connection to future SDK builds. It does not turn reporting on in applications that use those SDKs.
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. Already-installed versions never gain this connection.
Enable reporting in the application

The developer using the rebuilt SDK sets logging.enabled to true in its logging configuration. It ships false even after you enable Monitoring for the project. For example, TypeScript uses logging.enabled = true and Python uses LoggingConfig(enabled=True); follow the generated README for your language. Nothing is sent before this step.

Browser TypeScript and Python SDKs attach user, device/page context and breadcrumbs only after the application calls setLoggingConsent(true) following its own consent flow. Leave filterPii enabled: it defaults on and redacts sensitive keys before delivery.
Upload symbols from CI

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

Turning reporting on in an application

A developer using your SDK sets this when creating the client. These are from a generated TypeScript SDK.

const client = new Acme({
  auth: { bearer: process.env.API_TOKEN! },
  logging: {
    enabled: true,
    environment: "production",
    release: process.env.GIT_SHA,
    tags: { region: "eu" },
  },
});

Each language takes these in its own style, such as LoggingConfig(enabled=True) in Python, and the package's README shows the form. They can also be changed after the client is created, with setLoggingConfig (set_logging_config in Python and Rust, SetLoggingConfig in Go).

enabledbooleandefault: false

Turns reporting on. Nothing is sent until it's true, even after you enable Monitoring for the project.

releasestring

Which deploy this is, usually the git SHA. See releases.

environmentstring

Sent with each event, such as production.

userobject

Who's using the application, such as { id }. In TypeScript and Python it's sent only after consent. The other languages send it whenever it's set, after redaction.

tagsobject

Your own labels on each event, which you can search by.

filterPiibooleandefault: true

Redacts credentials and direct identifiers before anything is sent. Turn it off only for a private destination you trust.

consentbooleandefault: false

TypeScript and Python only. Whether personal data may be sent: the user, device and page context, and breadcrumbs. See consent.

maxBreadcrumbsnumberdefault: 30

TypeScript and Python only. How many recent actions are kept for context.

endpointURLdefault: your project's ingest address

Where events go. It's compiled into the SDK when you rebuild with Monitoring on, so leave it unless you collect events yourself.

apiKeystringdefault: your project's ingest token

The token sent with each event, compiled in alongside endpoint.

In TypeScript and Python, until the application calls setLoggingConsent(true) (set_logging_consent(True) in Python), personal data isn't sent: the user, device and page context, and breadcrumbs. Only the error and the operation are reported. Call it once your own consent flow has approved tracking.

Adding breadcrumbs

Breadcrumbs are the recent actions leading up to an error, shown with the event. The TypeScript and Python clients record HTTP calls for you, and an application can add its own with addBreadcrumb (add_breadcrumb in Python). The other languages send no breadcrumbs.

Seeing it working straight away

Send test event on the Logs tab sends one guided failure, to fill Logs, Issues, Traces, Performance and Releases with something to look at. You can use it once, and it doesn't need an SDK. From the CLI, use octri monitoring test-event.

Reporting from your own server

Generated SDKs show your customers' side. To see your server's side too, add a backend runtime.

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. Then the SDK user must enable reporting in their application. Until both opt-ins happen, the Monitoring tab stays empty.

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, and octri monitoring config prints all three values a CI job needs. See source maps.

Checking it works

Make a request through a rebuilt SDK whose application enabled reporting, then watch the Logs tab. Events stream in live, so if nothing appears within a few seconds, check both opt-ins and the installed SDK version.

What's kept

Raw events are kept 7 days on Free, 30 on Starter, 90 on Growth, 180 on Business and 365 on Enterprise by default (or the window in your Enterprise order form). Hourly rollups outlive raw events, so longer-range charts can still render after individual events expire.

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

Logs

The first thing you'll look at.

Readable stack traces

The step that makes the rest useful.

Redaction

What the SDK strips out before it reports anything.