Observability

Meridian exposes the identifiers you need to trace a call from your code, through our edge, to the resource and downstream webhook deliveries. This page is the debugging workflow.

The correlation chain

Every hop carries the same request_id - one identifier traces cause → effect → delivery.

Request IDs

Every response (success and error) returns Meridian-Request-Id:

Meridian-Request-Id: req_8fK2mPx4vL

Log it on every call. It's the single most useful thing when asking support to trace a request - we can pull the full edge-to-handler path by ID.

try {
  const project = await client.projects.create(params);
} catch (e) {
  if (e instanceof MeridianError) {
    logger.error("meridian.create failed", {
      code: e.code, status: e.status, requestId: e.requestId,
    });
  }
}

Tracing an event to its cause

GET /events/:id returns request_id - the API call that created the event (null for system-generated events):

{
  "id": "evt_3kR8mPx2vL",
  "type": "project.updated",
  "request_id": "req_8fK2mPx4vL",
  "sequence": 10492
}

From a delivery, the chain runs dlv_.event_id → evt_.request_id → the originating request. Useful for "which call triggered this webhook?"

Fields worth logging

Metrics to watch

• API error rate by code - rate_limited rising means you're over quota; 5xx rising may be us (check status).
• Webhook delivery success rate - sustained failures pause endpoints after 24h; alert on webhook.endpoint.disabled events.
• Event lag - time between a mutation and your handler processing it; spikes mean your receiver is behind.
• Retry-After compliance - if your 429s aren't followed by a quiet period, your backoff is wrong.

Dashboard views

• Request log (dashboard → project → Logs): filter by request ID, status, endpoint, time.
• Deliveries: per-endpoint success/failure with response bodies and retry state.
• Events: the per-project feed, filterable by type and time window.

Debugging workflow