Skip to main content
Every sampled production event produces a monitor_run, the verdict (pass / warning / error, or failed if the runner crashed), the source event reference, the judge invocation reference, and a decorated trace of which conditions matched. The Monitor detail page surfaces these two ways.

​
At-a-Glance

The top of the Monitor detail page shows a per-target card for each attached target:
  • Target type and its sample rate
  • The target’s error rate over the window
  • An error-rate sparkline (last 24h)
Use this to spot which target is misbehaving across a multi-target Monitor.

​
Activity chart

The Monitor Activity chart plots the error rate over time. Filters:
  • Targets: multi-select; defaults to all targets
  • Outcome: pass / warning / error
  • Bucket: hour / day depending on the time range

​
”Is this Monitor healthy right now?”

For agents, dashboards, and deeper analysis, the API exposes the underlying runs and rollups:
  • GET /monitors/{monitor_id}/metrics returns a single roll-up over a window, total sampled, pass/warning/error counts, rates, and the last-run timestamp. Add ?monitor_target_id=... for a per-target version.
  • GET /monitors/runs/by-source returns every monitor run that evaluated a given production event, useful for “what monitors fired on this request, and what did they say?”
  • Each monitor_run carries the decorated resolution trace (the resolution rule annotated with which conditions matched), the runner output, and runtime metadata.

​
Failed vs error

failed is reserved for runtime crashes, the runner itself blew up and we couldn’t compute a verdict. error is the normal “the resolution rule matched an error condition” case. They’re tracked separately so a noisy runner doesn’t silently inflate your error rate.