Issue counts look wrong

The Feed has rows, nothing looks empty or filtered away, but a number on it doesn’t match what you expected: a total that’s lower than you’d guess, a row that’s gone missing, or two columns that don’t seem to agree with each other. Find your symptom below:

• Total is lower than you expected: Counts only cover what got scanned
• Row you were watching has vanished: Duplicate clusters get folded together or The time range drops rows, but not their counts
• Events looks lower than the number of occurrences you know about: The Events column is really a trace count
• Trend sparkline doesn’t match the totals next to it: The Trend sparkline runs on a fixed 14-day window
• Count still doesn’t add up after accounting for sampling: The list mixes scanner and eval issues

Each row in the Feed is a cluster: one or more matching findings grouped into a single issue. See Understanding Error Feed for how clusters and categories form, and Error taxonomy for the fixed set a row’s category comes from.

Counts only cover what got scanned

Every project has a sampling rate between 0% and 100%, and it decides what fraction of traces are ever scanned in the first place. A count on the Feed only ever reflects scanned traces, never every trace that actually ran.

That gap gets big fast at a low rate. At a sampling rate of 20%, roughly one trace in five gets scanned, so five traces that hit the exact same failure can turn into a single scanned occurrence. Read literally, that looks like the error happened once. It happened five times; only one of those times got sampled.

Fix: if a count seems too low for how often you believe something is failing, that’s the sampling rate doing its job, not a bug in the count. Raise the rate so more traces get scanned. That only affects traces scanned from that point on; it doesn’t rescan what already ran, so counts you’re currently looking at won’t change. See Turn on Error Feed for where that control lives.

Duplicate clusters get folded together

Two clusters get folded into one when they’re in the same category, each is the other’s closest match in both directions, and the distance between them is within the merge threshold. If cluster A’s nearest neighbor is B, but B’s nearest neighbor is something else, they don’t fold. A mutual match in the same category that’s still too far apart doesn’t fold either; all three conditions have to hold together.

When a fold happens, the cluster with the larger member count absorbs the other, and the absorbed one stops appearing in the Feed as its own row. Its occurrences don’t disappear, they now count toward the cluster that absorbed it. So an issue you were watching yesterday can vanish from the list today, not because it resolved, but because it was the smaller, untriaged side of a mutual match and got absorbed into a bigger cluster in the same category. A cluster you’ve already triaged is protected from this: it survives the merge even if it would otherwise be the smaller side.

Fix: if a row you expected is missing, look for a similar issue in the same category with a higher count than you remember. That’s very likely where it went.

The Events column is really a trace count

A cluster row carries several separate counts, and what shows up in the Feed table isn’t a plain readout of them. The column labeled Events doesn’t count events at all, it renders unique traces, the number of distinct traces the cluster matched.

The Users column is a distinct end-user count, separate from Events.

Fix: don’t read Events as an occurrence count, it’s the unique-trace count sitting under a misleading header. Total occurrences aren’t shown as a column anywhere in the table.

The time range drops rows, but not their counts

Changing the Feed’s time range changes which clusters qualify for the list, not what their numbers say. A cluster only stays in the list when it was last seen within the selected range; narrow the range and clusters that fall outside it disappear from the table entirely. The Events and Users figures on a row that does survive aren’t windowed to that range at all, they’re lifetime values, so they don’t shrink just because you picked a narrower range.

Fix: if a row you expected is missing after narrowing the time range, that’s the row falling outside the last-seen window, not its counts dropping to zero. Widen the range and the row reappears with the same lifetime totals it always had.

The Trend sparkline runs on a fixed 14-day window

The Trend column doesn’t follow the time range you’ve set for the rest of the table. It’s labeled Trend (14d) and stays fixed at 14 days no matter what range you pick, so it won’t line up with the Events or Users totals sitting next to it in the same row. Those totals are lifetime counts, not range-bound ones, so this isn’t something you can tune away by adjusting the time range, the mismatch is permanent.

Fix: read the sparkline as a separate signal, not a breakdown of the totals beside it.

The list mixes scanner and eval issues

Issues on the Feed come from two different sources: the automatic scanner working through sampled traces, and evaluations. Both land in the same list and count toward the same totals unless you filter by source.

Fix: if you’re trying to reconcile a count against the sampling math in Counts only cover what got scanned and it’s not adding up, check whether some of the rows you’re counting are eval-created rather than scanner-created. Source isn’t a column in the Feed table, so you can’t tell by looking at a row; filter the list to a single source instead. See Issue fields & filters for the source values and the filter that isolates them.

Dive deeper