Skip to main content
This is the shortest supported path to first value with Node.js 18 or newer, jq, and LogBrew CLI v0.1.30 or newer. The CLI creates the project and stores its one-time ingest key without a dashboard handoff. Browser interaction is needed only when the CLI does not already have approved account authentication.
Use --json for agent workflows. Keep credentials in protected local configuration and pass only variable names between people, tools, and agents.

First project success path

1

Confirm account access

Install the CLI with the platform command in the CLI guide, then check its current account state before starting a new login.
Checkpoint: status reports authenticated account access. If it does not, a human runs logbrew login once and retries logbrew status --json. An agent must not start a new login when approved authentication already works.
2

Create one project from the CLI

Choose a new file in an owner-only directory. The CLI writes the one-time project ingest key to that file before it reports success. It never returns the key or its file path in output.
Project creation changes account state. The destination file must not exist. If a request has an ambiguous result, repeat the exact command so the CLI reuses its pending request identity. Do not change the request or use --abandon-retry unless you intend to start a different attempt.Checkpoint: output reports status: "created", setup status created, and an ingest-key kind. This proves that the project exists and the one-time key is stored; it does not prove telemetry delivery. See project setup and credential roles.
3

Install the Node.js SDK

Install the two published packages and load the stored key into the SDK-specific environment variable without printing it.
An account access credential is for account reads. Never use it as SDK configuration. Keep the project key out of command output, prompts, tickets, source files, and package configuration.
4

Send one safe SDK log

Send explicit release and environment markers with one placeholder-only info log. The stable event IDs make an exact retry deduplicate safely.
The event must not contain credentials, headers, raw request bodies, customer data, local paths, or unrelated source.Checkpoint: the SDK reports a successful status. Submission is not the readiness checkpoint; continue to the project doctor and authenticated readback.
5

Verify readiness with the project doctor

The CLI uses its stored account authentication for this read. Do not replace it with the project ingest key.
Checkpoint: state: "ready" with next_action.code: "inspect_recent_telemetry" and next_action.target: "telemetry_reads". For any other state, follow the returned typed action through the project diagnosis guide instead of guessing from logs.
6

Read the event and follow typed issue routing

Use the exact project, release, and environment from the SDK batch.
Checkpoint: LogBrew quickstart check appears in the fixed scope. If an issue is present, start from its authenticated detail response and follow only the returned next_action.code and next_action.target. Use the typed issue investigation workflow; never broaden the query across projects.
7

Recover safely or report privately

Follow the doctor’s typed action first. If telemetry is still missing, use the ordered first telemetry checks.When those checks cannot recover the path, create a private support ticket. Tickets are private to the submitting account and LogBrew support, but reports must still omit credentials, authorization headers, project IDs, hosts, raw logs or payloads, customer data, local paths, and source code. Use only the support guide’s strict diagnostic allowlist.

Continue with one task

Project setup

Diagnose setup state and manage project-scoped ingest credentials.

SDK ingestion

Review supported SDK packages and telemetry fields.

Issue investigation

Follow typed trace or related-log actions without widening scope.

Private support

Submit a sanitized, account-private recovery report.