Instrumentation — what Zespan can see, and who gets each layer

Settings → Instrumentation shows how well Zespan can see each layer of your stack, who is notified when a failure starts in a layer, and how your confirmations feed back. It explains the stack-layer attribution you see on issues, incidents and traces.

​

Layers seen in analysed failures

For the failures Zespan has analysed in the range you pick (24 hours, 7 days or 30 days), each row is one layer: The line above the table says how many layers were seen in every analysed trace. It is a count of coverage, never a grade: a layer you do not use is not a problem. The page is empty, with a plain message, until failures have been analysed. It is also empty for roles that cannot see attributions.

​

Gateway and OTLP data

Below the table, Gateway and OTLP data is the connection test for anything that exports OpenTelemetry traces to Zespan, including AI gateways. Point the exporter at https://api.zespan.com/v1/traces with your project key, send one request, then press Refresh. Each source that sent data in the last 30 days is a row, with counts for the last 24 hours: The card reports counts only: it never shows a payload, a header or a key. Until something arrives it says what to do. A test connection from the gateway (for example OpenRouter’s Test connection) shows as only a test connection has arrived until a real request follows. Everyone who can open the project’s dashboard can read it. Problems it names: The same data is available as GET /v1/projects/{id}/otlp-status in the API reference.

​

Who gets a failure, by layer

Under the table, Who gets a failure, by layer lets owners and admins pick, for each layer: How an incident is routed:

1. The layer’s Owner, when the incident’s origin is shown at Likely or better, or when it is Either … or … and both layers name the same owner
2. Otherwise the owner of the agent in the agent registry
3. Otherwise the earliest owner of your organization

The alert rule only adds channels; it never replaces the channels of the alert that opened the incident, and they are used for the notification sent when the incident is created. No new secrets are stored: a channel is whatever the alert rule already holds. When a person’s account is erased, they are removed from the mapping.

​

Confirm or correct the layer

Under a shown origin on an Issue or an Incident, Zespan asks Was it Retrieval? with Yes and No, it was…. When two layers fit equally, it asks Which layer was it?.

• Answering needs permission to manage incidents (owners, admins and editors, on the Team plan and above). Anyone else sees the recorded answer read-only
• The question appears only where the origin is shown to you. While attribution is in shadow mode only owners and admins see an origin, so only they can answer, and only they can read the recorded answer
• You can change your answer later with Change answer
• Each item has one current answer. The same answer twice is recorded once

What is stored: the item id, the layer Zespan claimed and its tier, the layer you chose, the role of the person who answered (for example admin), and the time. No name, no user id, no free text and no trace content is stored. Answers are kept for two years (730 days from the latest answer), then deleted, to measure how often an attribution is right. They do not change what you see: no answer, and no number of answers, shows or hides a claim on its own.

​

Next steps

• Stack layers: the layers, the tiers and when a claim is shown
• Issues: filter recurring failures by the layer they started in
• Incidents: who is assigned and notified
• Alerts: the rules whose channels a layer can reuse, including mcp_error_rate
• Traces: the Where it broke row