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
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.
info log. The stable event IDs make an exact retry deduplicate safely.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.
