Skip to main content
LogBrew stores first-party telemetry in four streams. They share the same project, service, release, environment, and trace context so agents can move between them without guessing. In plain terms, telemetry is the evidence your app sends out while it runs. A log says what happened, a trace shows where it happened in a request, an issue groups repeated failures, and an action records a product event.

Logs

Point-in-time messages from runtime, build, or application code. Logs are best for local facts such as route, user ID, status code, and error text.

Trace spans

Timed operations inside one distributed trace. Spans answer where time was spent and which operation failed.

Issues

Grouped failures. LogBrew turns issue events into stable fingerprints so repeated crashes become one issue with an occurrence count.

Actions

Product events. Actions answer what users or systems did, such as checkout_failed, invite_sent, or plan_changed.

​
Shared fields

​
Severity values

For streams that carry severity, LogBrew uses four canonical user-facing values: info, warning, error, and critical. Use the canonical values in dashboards, CLI output, API output, live responses, and examples. SDKs may accept common aliases as input compatibility, but unknown severity or level values are rejected.

​
Agent investigation pattern

1

Find the release

Read release summaries first to see which version has new issues, logs, trace spans, or actions.
2

Read unresolved issues

Grouped issues show the title, severity, message, status, first seen time, last seen time, and occurrence count.
3

Follow the trace

Use the issue or log trace_id to read all spans for the request.
4

Check actions

Actions show product impact, such as which users hit a failed checkout.