Why Did This Route Fire? The New Routes Tab Shows Every Clause
Until now, "why didn't this route fire?" required pulling up the route, reading the filter conditions, reading the event payload, and mentally evaluating the expression. The new Routes tab on the event debugger renders the per-clause pass/fail breakdown for every active route on the event's source — same code path as the live ingest evaluator.
The Question You Never Want to Re-Run In Your Head
You're looking at an event and one of the routes you expected to fire... didn't. Or one you didn't expect did. Until now, the only way to answer "why?" was to:
- Note the event's source
- Pull up each route on that source
- Inspect the route's filter conditions (either inline or referenced)
- Read the payload
- Mentally evaluate the conditions against the payload
Mentally re-running filter expressions is a thing humans are bad at. So today we added a Routes tab to the event debugger that does it for you.
What It Shows
For every active route on the event's source, the Routes tab renders:
- The route's name with a green check (passed) or red X (failed)
- A summary —
3/5 conditions matched (AND)or2/3 conditions matched (OR) - Each condition, individually —
field operator valuewithactual: <what we saw>and per-clause pass/fail icons - Edit link — straight to the route's detail page
If a route has no filter, we render "No filter — always fires" so you can see at a glance that it would have run regardless of payload.
The Implementation, Briefly
This piece is small but I'm proud of it. The ingest path already had evaluateFilterTrace — a side of our normal evaluateFilter that returns the per-condition breakdown for debug output. We've used it inside the simulator for a while. The event debug endpoint now uses the same code path against the stored event payload and every route on the event's source.
Because it's the exact same evaluator the ingest path uses, what you see on the Routes tab is what would have happened (and did happen) at ingest time. No drift between simulation and live evaluation.
Showing Up on the Tab Strip
The Routes tab only renders when there are active routes on the source — no empty state for sources with one route and no filter, since the answer would always be "yes, it fired, of course."
The tab label shows a passed / total badge so you can scan the event header and see "3/5 routes fired" without even clicking. If you're chasing down a missed-delivery problem, that count is usually the first thing you want.
Tier 2 In Action
This ships as part of the inbound debugging UX rollout — Tier 2 is "compounding wins" that build on the Tier 1 forensics view + cluster work. Filter eval trace is a Tier 2 win because it doesn't move you forward when everything's healthy, but it dramatically shortens the loop when something's wrong.