LogBrew docs

Choose the app or framework, create a project in Add Project, and verify the first signal before moving into CLI and dashboard references.

Choose platformOpen Add Project

Choose platform

Start with the app or framework that matches your project. Use the same choice in Add Project.

Filter platforms
6 of 26 shown

Node.js

Node.js service

Use the Node.js package when a backend service needs logs, request spans, actions, releases, and metrics.

npm install @logbrew/sdk @logbrew/node
Use the Node first-signal path

Express

Express service

Use the Express package when a Node service handles requests through Express middleware.

npm install @logbrew/sdk @logbrew/express express
Open Add Project

Fastify

Fastify service

Use the Fastify package when a Node service handles routes through Fastify plugins.

npm install @logbrew/sdk @logbrew/fastify fastify
Open Add Project

NestJS

NestJS service

Use the NestJS package when a Node service is organized around Nest modules and request handling.

npm install @logbrew/sdk @logbrew/nestjs @nestjs/common @nestjs/core @nestjs/platform-express reflect-metadata rxjs
Open Add Project

Python

Python service

Start with the core package for Python workers and services.

python3 -m pip install logbrew-sdk
Open Add Project

Django

Django app

Use the Django package for request and app signals from a Django project.

python3 -m pip install logbrew-sdk logbrew-django
Open Add Project

Install command

First successful SDK run

Keep the first session tight: install the package, create the project, send one non-secret product action, then confirm it in LogBrew.

  1. 1Install SDKUse the Node packages for a backend service that needs logs, spans, actions, releases, and metrics.
    npm install @logbrew/sdk @logbrew/node
  2. 2Create projectOpen Add Project, choose a platform, and copy the one-time ingest credential from the setup panel.Open Add Project
  3. 3Send one product actionRun the packaged example before wiring production code so the first shape is known and token-free.
    node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs
  4. 4Verify in LogBrewRead the first info signal in logs before adding more instrumentation.
    logbrew logs info --json
AI assistant context

Give an agent the public LogBrew map before it edits your app or setup command.

curl -L https://logbrew.co/llms.txt
installation promptRead https://logbrew.co/llms.txt, then choose the matching SDK card at https://logbrew.co/en/docs#docs-sdk-choice-title. Use npm install @logbrew/sdk @logbrew/node only for a server-side Node.js service; for Next.js, React, iOS, Android, or React Native, use the selected card and Add Project prompt. Ask the signed-in user to open Add Project and place credentials only in the matching app environment. For server-side Node.js, the env var is LOGBREW_SERVER_API_KEY. Run node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs only for Node services, then verify with logbrew logs info --json. Do not ask for credentials in chat or commits.
Open agent guide
Send the first Node SDK signal to LogBrew

Use this Node path when you want live project data, not another setup article. The dashboard creates the project and shows the one-time credential; the public docs keep the package and verification steps safe.

  1. Add the JavaScript SDK packages

    Start with the core SDK and Node helper when a backend service needs logs, request spans, actions, releases, and metrics.

    npm install @logbrew/sdk @logbrew/node

  2. Create the project from Add Project

    Sign in, open Add Project, choose a platform, and copy the one-time ingest credential from that setup panel. The website does not repeat it after you leave.

    Open Add Project

  3. Run the first SDK signal example

    Use the installed package example to inspect the release, environment, request span, product action, network milestone, and metric shape before wiring your app.

    node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs

  4. Read the first signal in LogBrew

    After the SDK sends an info signal with the project credential, use the CLI or dashboard logs view to confirm it arrived before adding more instrumentation.

    logbrew logs info --json
Docs surfaces3

docs.logbrew.co

Full docs site

Use the dedicated docs site for long-form setup, API details, and examples that should not crowd the product landing pages.

Open docs site

Plain text

Markdown docs mirror

Use the localized Markdown mirror when an agent or terminal workflow needs the same docs without browser-only state.

Open Markdown

Plain text

Agent mirrors

Use llms.txt, Markdown mirrors, robots, and sitemap when an agent needs predictable public reading paths.

Open llms.txt
Choose your path3

Set up

Check whether LogBrew is ready

Run status first to confirm reachability, login state, and the next safe read.

logbrew status --json

Triage

Start from the latest failures

Read recent error logs, then move into issues or traces when a release or project needs context.

logbrew logs error --json

Hand off

Share a stable issue view

List open issues when a teammate needs the same failure groups.

logbrew issues open --json
Command map6

Command map

Status

Check local auth, API reachability, and recovery steps before any private read.

logbrew status --json

Command map

Logs

Start with recent errors when a release, project, or trace needs context.

logbrew logs error --json

Command map

Issues

List open failure groups before deciding whether to resolve, close, ignore, or reopen.

logbrew issues open --json

Command map

Trace detail

Read a known trace id when logs or issues point to one failing request.

logbrew trace <trace_id> --json

Command map

Actions

Filter user events by name when the important context is a product action.

logbrew actions --name checkout_failed --json

Command map

Releases

Compare rollout context with log, issue, trace span, and action counts.

logbrew releases --json
LogBrew docs4

CLI first

Check local auth and API reachability

The first read should tell you whether the CLI can reach the LogBrew API without exposing token material.

  • Use JSON mode when a script or automation needs stable fields.
  • Use human output when a developer needs the next command.
  • Keep auth recovery pointed back to login and status.

Observe

Read production signals by resource

Logs, issues, actions, traces, releases, and projects should stay separated enough to scan quickly and connected enough to recover context.

  • Logs keep severity, release, environment, project, trace, and search filters.
  • Issues keep status, trace context, and mutation vocabulary.
  • Traces keep span names, release context, environment context, and project scope.

Share

Send useful context without exposing project data

Use public docs, Markdown, and copyable commands when someone needs setup help or a safe handoff.

  • Share a docs link when the next step is setup or command discovery.
  • Share Markdown when plain text is easier than a screenshot.
  • Keep dashboard project data behind login and backend auth.

API map

Match the dashboard to backend routes

The web workspace should follow documented LogBrew API contracts instead of inventing dashboard-only storage or alternate contracts.

  • Logs read from /api/logs with severity, release, environment, project, trace, and search filters.
  • Issues read and mutate through /api/telemetry/issues and /api/telemetry/issues/{issue_id}.
  • Actions, releases, and trace detail read through /api/telemetry/actions, /api/telemetry/releases, and /api/telemetry/traces/{trace_id}.
  • Projects and auth state come from /api/projects, /api/auth, and CLI status commands.