Tracing
Tracing shows what your application’s agent did, step by step: each model call and tool call, errors, latency, tokens, and the code version that ran. WeHarness reads traces to help you find why something failed. Traces are evidence of what happened; they do not prove a cause on their own.
Traces arrive over OpenTelemetry (OTLP/HTTP). Use the WeHarness SDKs for Python and Node.js, or any OpenTelemetry SDK. See Set up tracing.
Applications
Section titled “Applications”Tracing in the sidebar opens on your applications: each agent you run, with its repository, environments, the time of its last trace and how many traces failed in the last 24 hours. Connect an agent creates one: a name and, optionally, a GitHub repository. An application without a repository works for tracing; evaluations, lessons and code search need the repository.
Inside an application, choose the environment at the top. The tabs are:
| Tab | What it shows |
|---|---|
| Traces | The trace list, the failing calls, and one trace at a time. See Reading a trace. |
| Releases | How each release behaved, and two releases compared. See Releases. |
| Online evaluators | Evaluators that score live traces. See Online evaluators. |
| Automations | Rules that act on failing or low-scored traces. See Automations. |
| Setup | The setup wizard, ingest keys, what arrived per key, and the sessions sending traces. |
While an application has no traces, its page is the setup wizard. It moves to the trace list by itself when the first trace arrives.
Ingest keys
Section titled “Ingest keys”An ingest key lets your application send traces to one application, for one environment. It starts with whk_.
- It is shown once, when it is made. Keep it in an environment variable or a secret store, never in your code or in browser code.
- It can only send traces. It cannot read anything.
- Its environment is a short lowercase name, for example
local,stagingorproduction. - Keep prompts and outputs is off by default: the key then sends metadata only. See What is kept.
- Revoking a key stops it at once.
Owners and admins make and revoke keys, in Setup or with Generate key in the wizard. A coding tool can make one over MCP with tracing_setup; it is shown once there too.
Sessions and applications
Section titled “Sessions and applications”A session’s traces show in an application only when an owner or admin links the session to it (Setup → Sessions sending traces). A matching repository never links traces by itself, and unlinking stops it at once. Each trace says which key, environment and session sent it.
Deleting a session revokes its ingest keys and deletes the traces they sent. An owner or admin can instead choose, in the delete confirmation, to move the keys and their traces to an application: the running application keeps sending, and its traces stay with the application.
What is kept
Section titled “What is kept”| Metadata | Span names, times, status and error messages, model and tool names, token counts, the service and its version, the commit, and where in the code a tool ran |
| Content | Prompts, model outputs, tool arguments and results, and request and response bodies are removed when they arrive, unless the ingest key keeps content. Each span counts what was removed. Removal works on the attribute names that carry content (the OpenTelemetry GenAI names and common equivalents); span names, status messages and other attributes are kept, so do not put content or secrets in them. |
| Retention | 14 days from each span’s time, then deleted automatically |
| Limits | 128 attributes per span; long values are shortened; requests up to 5 MB |
The WeHarness SDKs remove the same content attributes before spans leave your process, unless you turn content capture on. See SDK reference.
The workspace and project come from the ingest key, never from the data your application sends. Spans with broken ids, or with times more than 7 days in the past or an hour in the future, are refused and counted. A span that arrives twice counts once. Copies with different content are flagged, not merged.
Where in the code
Section titled “Where in the code”Tool calls made with the SDK helpers record where your code called them (code.file.path, code.line.number, code.function.name), relative to the directory your application runs from. Other spans can set the same attributes. WeHarness keeps them only in an allowlisted shape: a relative path (absolute roots and home folders are stripped), a line number and a function name without its arguments. A raw stack (exception.stacktrace) is content: it is removed unless the key keeps content.
Credits
Section titled “Credits”Reading traces uses no credits. 10,000 spans a month are included, then each 1,000 spans use 1 credit, counted over the month. A span is one step of a trace. See Credits and usage.
Who does what
Section titled “Who does what”| Owner, admin | Member | Viewer | |
|---|---|---|---|
| Read traces, releases and scores | ✓ | ✓ | ✓ |
| Create an application | ✓ | ✓ | — |
| Make and revoke ingest keys, link sessions | ✓ | — | — |
| Attach online evaluators, activate automations | ✓ | — | — |
Over MCP, a coding tool reads traces with traces_search and trace_get. See Tools and prompts reference.