Monitoring & observability
The dashboard's Monitor section shows what's flowing through the gateway in real time and after the fact: a Live feed, searchable request Logs, a Reliability view, and Reports. This page covers each surface and the headers that unlock per-session attribution.
Live Monitor
The Live Monitor streams completed (and in-flight) requests over Server-Sent Events:
GET /api/eventsEach event carries the provider, resolved model, HTTP status, token counts (prompt / completion / cache read / cache write / reasoning), latency, cost and charge, the gateway key label, the session id, and — on failure — an error_message. Events come in two phases: started (in-flight) and completed (finished), correlated by a stable request_id.
The stream is auth-gated when a dashboard password is set or multi-tenant mode is on (the token may arrive as Authorization: Bearer or a ?token= query param so browsers' EventSource can use it). In the wide-open local default it's open like the rest of the dashboard.
Request Logs
GET /api/logs # filtered, paginated list (metadata)
GET /api/logs/{request_id} # full detail incl. attempt timeline
GET /api/logs/{request_id}/export # detail as downloadable JSON
DELETE /api/logs/{request_id} # remove a single row + its bodiesThe list supports filtering by provider, model, source, session, api_key_id, a status shorthand (success / error / client / server), a since/until window, and a free-text q over the error message and model names. Each row records the source wire format, attribution (key, account, session), the requested vs resolved model, the outcome (status, error_kind, error_message, tokens), economics (cost, charge, latency, TTFB), and the per-attempt fallback timeline.
Body capture & the privacy posture
Capturing full request/response bodies is OFF by default — merido is privacy-first, so by default only metadata and (redacted) headers are stored. You can change this:
- Set
MERIDO_LOG_BODIES=trueat startup, or - Toggle it at runtime from the Logs page (persisted via
PUT /api/settings, no restart needed).
Two important details:
- Capture applies to future requests only. Turning it on does not retroactively fill in bodies for requests already logged.
- Failed requests are an exception. Even with blanket body logging off, bodies of requests that fail (status ≥ 400) are retained so you can inspect what went wrong post-hoc.
Whenever bodies are stored, they're scrubbed first: secrets are masked and PII (emails, phone numbers) is replaced before the body is compressed and written. Logs are pruned by age (MERIDO_LOG_RETENTION_DAYS, default 30) and total size (MERIDO_LOG_RETENTION_MAX_BYTES, default 2 GiB).
Attribution headers
To group and attribute traffic by session, agent, or cost center, send these request headers (the first match wins for each):
- Session —
x-merido-session(also acceptsx-claude-code-session-id,x-session-id). - Agent —
x-merido-agent(alsox-claude-code-agent-id,agent-id,x-agent-id). - Cost center —
x-merido-cost-center, for chargeback grouping in Reports (falls back to the gateway key's default cost center).
The request's source (its wire format — OpenAI / Anthropic / Responses / Gemini) is recorded automatically and is filterable in Logs and Reports.
Reliability
GET /api/usage/reliability?window=24hReports per-model error rate and truncation rate over a window (24h / 7d / 30d / all), so you can spot a flaky provider or model at a glance.
Reports & trends
GET /api/usage/timeseries?window=24h&group_by=provider # spend / tokens over time
GET /api/reports?group_by=cost_center&format=json|csv # showback / invoices
GET /api/sessions/{session_id}/cost # one session's burn rateReports group spend and tokens by cost_center, model, source, day, api_key, user, virtual_model, and more, and export as JSON or CSV. The charge and margin columns are meaningful in multi-tenant mode (where a virtual-model markup can make charge differ from cost); in single-user local mode charge equals cost.
Related
- Usage & the Advisor — the cost/savings analytics layer on top of usage.
- Audit log & SIEM export — the control-plane change log (separate from request logs).
- Configuration —
MERIDO_LOG_BODIESand the log-retention knobs.