Connecting server logs

This is Tripwire's deepest feature and its hardest-to-copy seam: correlate a UI failure to the backend error that caused it. When a failing request carries a trace_id and you've connected a log backend, Tripwire fetches the matching server log lines and Claude synthesizes the backend error, the suspected cause, and a suggested fix — attached to the run report and the filed issue.

The mechanics of the trace_id → logs → diagnosis chain are in Self-heal & root-cause.

How correlation works

1. During a case, the Playwright driver records every failed network response — including the traceparent header — and extracts a trace_id.
2. When an assertion fails, Tripwire calls the configured log backend with that trace_id, querying a recent time window (default ~3 minutes back, up to 200 lines).
3. Claude reads the matched log lines plus the UI failure and the failing request, and returns a structured diagnosis: category, server_error, suspected_cause, suggested_fix, confidence, and up to five evidence lines.
4. That diagnosis is merged into the issue and report.

Your app needs to do one thing for this to work: propagate a trace id (the standard traceparent header is ideal) and log it server-side, so a UI request and its backend log line share an id. The whole chain is best-effort — if there's no trace_id or no backend configured, you still get the in-browser root cause; the server enrichment is purely additive.

Choose one backend

Connect exactly one backend via Settings or environment variables. Set LOG_BACKEND to one of loki, datadog, elasticsearch, http, or file, plus its config.

Like the issue trackers, use a dedicated, read-only Tripwire token for the log backend (e.g. a scoped Datadog or Elasticsearch API key) — set once by an admin, not an engineer's personal key.

Loki

LOG_BACKEND=loki
LOKI_URL=https://loki.example.com
LOKI_SELECTOR={job=~".+"}          # optional; default {job=~".+"}

Queries GET {LOKI_URL}/loki/api/v1/query_range with <selector> |= "<trace_id>" over the window.

Datadog

LOG_BACKEND=datadog
DATADOG_API_KEY=...
DATADOG_APP_KEY=...
DATADOG_SITE=datadoghq.com          # optional; e.g. datadoghq.eu

Posts to https://api.<site>/api/v2/logs/events/search filtered by the trace_id.

Elasticsearch

LOG_BACKEND=elasticsearch
ELASTIC_URL=https://es.example.com
ELASTIC_API_KEY=...
ELASTIC_INDEX=logs-*                # optional; default logs-*

Posts a query_string search for "<trace_id>" against {ELASTIC_URL}/{index}/_search, reading message / log from each hit.

Custom HTTP endpoint

Expose your own endpoint that accepts ?trace_id= and returns log lines — the simplest way to connect a homegrown logging system.

LOG_BACKEND=http
LOG_HTTP_URL=https://logs.example.com/search
LOG_HTTP_TOKEN=...                  # optional; sent as Bearer auth

The response is normalized flexibly: a JSON array of strings, an object with a logs / lines / results / data array, or plain text (split by line) all work.

File

Point at a log file or JSONL dump — perfect for local testing and the bundled demo.

LOG_BACKEND=file
LOG_FILE_PATH=/var/log/app/server.log

Tripwire scans the file for lines containing the trace_id. The sample app uses exactly this:

LOG_BACKEND=file
LOG_FILE_PATH=examples/sample-app/server.log

See it end-to-end

cd examples/sample-app && uvicorn app:app --port 8500     # the buggy demo app
backend/.venv/bin/python demo/break_demo_app.py         # find the bug AND the backend reason

The German checkout silently shows USD instead of EUR (HTTP 200 — nothing throws in the browser), and POST /api/checkout?cc=DE returns a 500 logging [ERROR] trace=<id> GeoLookupError …. Tripwire's absent_text: ["USD"] check fails the run, resolves the failing request's trace_id to that exact server.log line, and Claude writes up the backend error + suspected cause + suggested fix — filed as a deduped ticket.

What you get in the issue

When correlation succeeds, the filed issue's Root cause section gains a Server diagnosis block:

Server diagnosis (backend_exception, confidence 0.82)
- Error: GeoLookupError: no region for country code 'DE'
- Suspected cause: the pricing service maps country → currency via a table missing 'DE'
- Suggested fix: add 'DE' → 'EUR' to the currency map, or fall back to EUR for EU codes
- Log evidence:
  [ERROR] trace=… GeoLookupError: no region for country code 'DE'

See Filing issues for the full issue anatomy, and Settings & env for every variable in one place.