Monitor guardrail decisions
See how live guardrails behave in production — runtime stats, per-decision scores on traces, and the Guardrail Triggers trace filter.
Monitor guardrail decisions
Every time a guardrail runs — whether it passed, blocked, redacted, or was skipped — the decision is recorded as a score on the trace. That gives you three ways to see guardrails in action: a per-guardrail runtime stats panel, guardrail decisions on each trace, and a Guardrail Triggers filter over your traces.
How a decision is recorded
Each guardrail decision becomes a categorical score named guardrail:<name>, with a source of GUARDRAIL. The decision value is one of:
| Decision | Label | Meaning |
|---|---|---|
passed | Passed | The rule ran and did not match |
redacted | Redacted | A redact rule matched and rewrote the content |
blocked | Blocked | A blocking action stopped the call |
failed_open | Skipped | The rule could not be evaluated, so the call proceeded unenforced |
Because decisions are scores, they flow through the same trace, filtering, and analytics surfaces as your other evaluation scores.
Runtime stats
Open a saved guardrail from the evaluator library — the editor shows a Runtime · last 7 days panel alongside its parameters. (The panel appears only for an existing guardrail, not while you're creating a new one.) These numbers come from the SDK's enforcement decisions on your live traffic, so the panel stays empty until the SDK has enforced this guardrail at least once.
| Metric | Meaning |
|---|---|
| Decisions | Total decisions the guardrail made in the window |
| Triggered | Count of blocked + redacted decisions |
| Skipped | Share of checks that were skipped (proceeded unenforced), as a percentage |
| Latency p50 / p95 / p99 | Enforcement latency as measured on your live traffic |
| Skip reasons | Breakdown of why checks were skipped (see below) |
For LLM-judge guardrails, the panel also shows an estimated judge cost per decision and over the window.
Latency and judge cost reflect real enforcement on your live traffic. If there are no decisions yet, the panel shows an empty state; decisions appear once the guardrail is enforced on live traffic.
Skip reasons
When a guardrail is skipped, the reason is recorded so you can tell a benign pass-through from a misconfiguration:
| Reason | Label |
|---|---|
timeout | Judge timeout |
missing_creds | Missing judge credentials |
throw | Rule error |
budget_breach | Budget breach |
regex_timeout | Regex deadline |
server_outage | Server outage |
malformed_payload | Malformed rule payload |
payload_too_large | Payload too large |
Guardrail decisions on a trace
On the Trace Detail page, the Scores tab groups guardrail decisions into their own Guardrails section (marked with a Runtime pill), separate from your post-hoc evaluation scores. The section header summarizes the trace — for example, "3 decisions · 1 triggered".
Each decision row shows:
- The guardrail name, linking back to the guardrail in the evaluator library.
- The decision — Passed, Blocked, Redacted, or Skipped.
- The hook point and action that ran.
- The enforcement latency in milliseconds.
Hovering a guardrail score chip in the trace tree opens a card with the Hook point, On match action, Latency, Retry attempt (when a re-ask occurred), and Skip reason (when applicable), plus an Open guardrail → link.
Filter traces by guardrail activity
The traces table has a Guardrail Triggers filter. It is a boolean filter that matches any trace where at least one span carried a guardrail decision — that is, where the SDK's runtime enforcement fired.
Use it to jump straight to the traffic your guardrails acted on, for example when reviewing what a newly promoted guardrail is catching in production.
The Guardrail Triggers filter appears only when guardrails are enabled for the project. It is a filter, not an export column.