Skip to main content

Debug checklist

When something isn’t working, run through this list first:

Common errors

401 Unauthorized

Cause: API key is missing, malformed, or revoked. Fix:
  • Confirm TRACELANE_API_KEY starts with tlane_.
  • Check the key hasn’t been revoked in Settings → API Keys.
  • Revocation takes effect at the gateway within 60 seconds; a key that has been idle for over a minute may be accepted once more on its next use while the gateway re-checks it.
  • For JWT auth: confirm the organizationId claim is present and the JWKS URL is reachable from the gateway.

403 Forbidden — entitlement check failed

Cause: The feature you’re trying to use requires a higher plan. Fix: Check your current plan in Settings → Billing. See the pricing page for which features are on which tier.

429 Too Many Requests

Cause: Per-tenant rate limit exceeded. Fix: The gateway uses a token-bucket rate limiter per tenant. Implement exponential backoff with jitter. The Retry-After header gives the wait time in seconds.

502 Bad Gateway from provider

Cause: The upstream LLM provider returned an error (5xx, rate limit, or timeout). Fix: Same-provider retry is automatic. CROSS-PROVIDER failover is opt-in per request via the X-Tracelane-Failover: cross-provider header and is off by default; when enabled it tries 500 / 502 / 503 / 504 along the configured chain. A 429 is not eligible for failover — it is returned to you with Retry-After. If failover is exhausted, or the request targets a single provider with no downstream in the chain, the upstream error is proxied back. A workspace can set its own ordered fallback models in settings — see Failover.

predictive.verdict = block — guardrail finding

Cause: A guardrail recorded a block verdict. In observe-first mode the request can still reach the provider; with enforcement enabled, a preflight block returns 403 before dispatch. Fix: For a recorded span, check its guardrail attributes and use the MCP tool explain_guardrail_block with trace_id and span_id. For a preflight 403, there is no trace span; use the response body’s correlation_id with the same tool.
Switching a guard from block to warn is a workspace policy setting.

Traces not appearing in the dashboard

Possible causes:
  1. SDK not initialized — confirm tracelane.init(endpoint=…, api_key=…) runs at startup (both arguments are required; there is no env-var auto-read).
  2. Client not wrapped — constructing a client does not capture it. Call the matching instrument_* on each client after init(). auto_instrument() only covers anthropic, openai, litellm, and claude_code — everything else needs an explicit instrument_* call.
  3. Wrong endpoint — on Cloud, endpoint is https://gateway.tracelane.dev (the SDK appends /v1/traces), not the dashboard URL. Self-hosting, it is the OTLP receiver you run.
  4. 403 insufficient_scope — the key is missing the ingest scope. The response body names it. Mint a key with Ingest ticked in Settings → API Keys; keys minted before scopes existed are unaffected.
  5. Ingest lag — spans can take up to 5 seconds to appear after the request. Wait 10 seconds and refresh.
  6. Sampling rate — if sample_rate < 1.0, only a fraction of requests are captured.
To force pending spans out (e.g. in a short-lived script), call shutdown() at exit and confirm your OTLP receiver / gateway logs show the delivery:

ClickHouse connection errors (self-host)

Fix:
  • Confirm CLICKHOUSE_URL is reachable from the gateway container.
  • For Neon ClickHouse: confirm the connection string uses HTTP, not HTTPS, unless your cluster terminates TLS.
  • Check docker compose logs clickhouse for startup errors.

WorkOS webhook not provisioning tenants

Symptoms: User signs in but has no tenant row in Postgres; dashboard shows “No organization in session” error. Fix:
  1. In WorkOS dashboard → Webhooks, confirm the webhook is pointing to https://gateway.<your-domain>/v1/webhooks/workos and is active.
  2. Check gateway logs for workos_webhook entries:
  3. Confirm WORKOS_WEBHOOK_SECRET matches what’s shown in the WorkOS dashboard.
  4. Replay the failed webhook events from the WorkOS dashboard.

Enable debug logging

Get help