Observability

Syntax exposes a small but complete observability surface so you can see what's happening at runtime without digging through log files. The same controls work for local inference, self-hosted remote, and managed remote deployments.

What's instrumented

For every deployed model and every request through the Bridge, Syntax collects:

• Metrics. Tokens in / out, latency, request count, error rate, deployment health.
• Traces. Per-request traces showing each step of the routing pipeline.
• Crash dumps. When an inference engine or a tool call crashes, Syntax keeps a dump on disk so you can investigate.
• Request logs. Optional structured logs of every chat request.

Each is independently configurable.

Where you control it

The desktop app's Observability page lets you:

• Toggle metrics, tracing, crash dumps, and request logging per deployment and globally.
• Pick a tracing destination — local file, your own OpenTelemetry collector, or none.
• Pick a metrics destination — local Prometheus-compatible endpoint, your own Prometheus scraper, or none.
• Set request-log retention.

The same controls work for local, self-hosted remote, and dUX-managed remote deployments. Managed-remote observability data flows back through dUX into Syntax so you don't need a separate observability stack on the cloud side.

What's surfaced in the UI

The desktop app also surfaces a small set of high-leverage signals inline so you don't have to look at metrics dashboards:

• Active Deployments shows live token / request counters per deployment.
• Sessions shows per-session usage and budget consumption.
• Status badges indicate when a deployment is degraded.
• A consolidated Issues panel groups warnings ("a deployment is out of memory", "a remote target stopped responding") so they're visible without you opening a log file.

Privacy

Observability is local by default. Metrics, traces, and request logs all stay on your machine unless you explicitly point them at an external collector. Org admins can require that observability data flows through the org's collector for audit purposes.

When to enable each

• Metrics: always. Cheap, useful for capacity planning.
• Tracing: when you're debugging a routing issue or a slow request.
• Crash dumps: leave on; they don't cost anything until something crashes.
• Request logging: enable when you need to debug a specific flow or when org policy requires it. Otherwise leave off — it generates the most data.

Where to go next

• Inference → Overview — what each inference target reports.