Observability

The most expensive turn in any change loop — whether the author is you or an AI agent — is the verification turn: did the change actually work, across every process it touched? This pillar is how NetScript answers it. The runtimes emit real OpenTelemetry spans, a single W3C traceparent groups a cross-process flow into one distributed trace, structured logs ride the same OTLP export, and both a dashboard and a typed query port read it all back — for you, or for an agent verifying its own change. Use this pillar when you need to add tracing, inspect runtime behavior, or connect package-level telemetry to the running system.

Where to go next

Telemetry in NetScript is built-in, not bolted-on — the fastest route is to see a trace first, then learn the model:

• Emit and view a trace: Telemetry & logging

  is the capability hub — automatic worker spans, the @netscript/telemetry helpers, browser logs, and the dashboard views, with Add OpenTelemetry

  as the task recipe.

• Understand the model: Observability

  maps what is framework-real versus a scaffold stub, and how trace context propagates across process boundaries.

• See where telemetry is collected: Orchestration with Aspire

  explains the dashboard and OTLP collector the AppHost provisions; trace context crosses service boundaries at the services seam.

• Read a trace back in code: the Telemetry & logging

  hub's Close the loop section covers the typed TelemetryQueryPort read side — how a test or an agent asserts a span landed instead of eyeballing the dashboard.

• Look up exact symbols: telemetry and

logger references, and the telemetry convention (span naming, SpanKind, the netscript.* attribute rules).

Learn, do, look up