Setup

Local debugging works best when your app, tests, and commands leave a queryable trail. Set up the local collector first, export development telemetry to it, then use Everr queries as the source of truth while you debug.

The intended result is simple: after you reproduce a local issue, you can ask what happened with SQL instead of reconstructing it from terminal scrollback.

Start the local collector

Everr Desktop starts the local collector while the desktop app is open. If Everr Desktop is running, you do not need to start a separate collector process from the CLI.

Check whether the collector is already running:

everr local status

If it is stopped, start it in a separate terminal:

everr local start

everr local start runs in the foreground and prints the OTLP HTTP endpoint when it is ready.

Point your app at the local endpoint

For local development and tests, configure your OpenTelemetry SDK to export to the otlp endpoint printed by everr local status or everr local start.

export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:54318"
export OTEL_SERVICE_NAME="my-app"

Some SDKs accept the base endpoint and add signal paths automatically. If your SDK asks for per-signal URLs, use:

Keep local exporter configuration gated to development and test environments. For production export, use Production Monitoring instead of shipping local collector URLs.

If your app does not emit OpenTelemetry yet, use everr-setup-telemetry to add the smallest standard setup for your stack.

Capture command output

Use real OpenTelemetry for runtime services. For bounded commands that do not emit OpenTelemetry, wrap the command so stdout, stderr, and the exit code land in local telemetry:

everr wrap -- pnpm test

The command still prints normally and keeps its original exit code. The wrapped logs are useful for test failures, lint output, build errors, and short scripts that need to be queryable after the terminal output scrolls away.

Set up your assistant

Install the Everr skills from Skills so your assistant knows when to use local telemetry and how to query it during an investigation.

When you ask for help with a local bug, ask for an evidence loop:

Use Everr local telemetry for this investigation. Check collector status,
query recent traces or logs before changing code, and add targeted debug
telemetry if the current data does not explain the behavior.

That gives the assistant a concrete workflow: inspect existing telemetry first, instrument only the missing facts, reproduce the issue, then compare observed state to expected state.

Troubleshooting

• Collector stopped. Run everr local start or open Everr Desktop.
• No traces or logs. Confirm the app started after OTEL_EXPORTER_OTLP_ENDPOINT was set, then trigger the instrumented path.
• Browser telemetry is missing. Check the browser console for CORS or CSP errors and make sure the local exporter is dev/test gated.
• Only command output appears. everr wrap captures stdout and stderr, not application spans. Add OpenTelemetry instrumentation for request flow, database calls, background jobs, and errors.
• The assistant cannot explain the bug from telemetry. Add a small debug span, event, or log for the missing value, then reproduce the issue again.

Next, learn how to use debug traces for manual investigations and assistant-led debugging loops.