Monitoring & APM

Execution traces tell you what happened inside a single run. Monitoring is different: it's an opt-in, ongoing view of how a deployed agent is behaving over time, independent of any one run.

The monitor-agent sidecar

Monitoring is powered by a sidecar process, monitor-agent, that runs alongside a deployed agent and pushes metrics back to the platform. It's opt-in — an agent isn't monitored unless you enable it — and every metric push is:

• Consent-gated — metrics only flow if monitoring has been explicitly turned on for that deployment.
• Token-authenticated — the sidecar authenticates each push with a monitoring token issued at deploy time, so metrics can't be spoofed or injected by an unrelated process.

The APM dashboard

The APM dashboard reads the metrics monitor-agent pushes and gives you a running picture of agent health: how the deployed agent is performing over time, rather than a play-by-play of one run.

How it differs from a run trace

It's easy to conflate monitoring with the per-run execution trace, but they answer different questions:

• Execution trace — "what did this one run do, step by step?" Sourced from the run itself, available immediately, always on for every run.
• APM dashboard — "how is this deployed agent doing overall?" Sourced from the monitor-agent sidecar, opt-in, and scoped to health over time rather than a single run's steps.

If you're debugging one specific run that misbehaved, start with its execution trace. If you're checking whether a deployed agent is healthy right now, or has been over the past period, that's what the APM dashboard is for.

Enabling monitoring

Monitoring is tied to deployment: when you deploy an agent version, you can opt it into monitoring, which provisions the monitor-agent sidecar and its authentication token for that deployment. If you later deploy a new version or roll back, monitoring carries forward with the deployment rather than needing to be reconfigured each time.