Analysis Tools
Reachability Analysis

Reachability Analysis

Your rule has 47 rows. Which ones actually matter?

Reachability Analysis shows you exactly which rows are being hit by real traffic—and which ones might be dead weight. It analyzes your execution logs to surface usage patterns you wouldn't otherwise see.

Reachability Analysis

What It Shows

Which rows are doing the heavy lifting:

  • Rows sorted by hit frequency, most matched at top
  • Percentages showing traffic distribution
  • Rows that were never hit flagged as potential dead code

The panel header shows summary stats: how many requests matched at least one row, how many matched nothing, and how many rows have zero hits.

⚠️

High "no match" counts mean inputs are falling through without being handled. You probably need a catch-all row or broader conditions.

Finding Dead Rows

A row with 0% hits over 30 days is probably:

  • Unreachable — an earlier catch-all row blocks it
  • Obsolete — handles an edge case that never actually occurs
  • Safe to remove — cleaning up your rule table

Before deleting, check why it's not being hit. Some rows handle rare but critical cases—you don't want to remove your fraud detection row just because it only fires twice a month.

Performance Optimization

If one row handles 80% of your traffic but sits at the bottom of your table, moving it up can meaningfully improve evaluation speed at scale. Rulebricks evaluates top-to-bottom, so putting your high-traffic rows near the top reduces unnecessary condition checks.

Use Impact Analysis afterward to verify that reordering didn't change your rule's behavior.