get_collection_health flags a healthy query_store collector as regressed: its 5-minute cadence produces zero-row runs every hour by design #4473

Claude posting for Erik Darling

get_collection_health flags a healthy query_store collector as regressed_from_productive: true (WARNING). The produced-then-stopped rule (#3885) fires after 3 consecutive zero-row successes, and a query_store collector at its 5-minute cadence has runs of zero-row successes every hour by design.

Seen

One monitored server on a production SQL Server store, query_store collector, collection_log over 3 days (2026-09-24 → 2026-09-27), hourly:

• Every hour: 9–12 runs, of which 7–10 are SUCCESS with 0 rows. The rest carry all the rows (a daily cycle of about 4–11 k rows/h from 06 to 11 UTC and 26–31 k/h from 16 to 23 UTC).
• The shape is the same on all three days, with no drop at either service install in the window, and SUCCESS throughout.
• get_collection_health reports the collector as WARNING with regressed_from_productive: true, although nothing regressed.

Why

• CollectorHealthClassifier.ProducedThenStopped (PerformanceMonitor.Common/ServerHealthBands.cs) is true when the trailing zero-row-success streak reaches ProductiveZeroRunStreak (3) and the collector produced earlier in the window. Event and on-load collectors are excluded.
• The constant's comment reasons from collectors whose source changes every cycle: "three consecutive runs is 3–15 minutes of a source returning nothing … the shape that does not happen by accident."
• query_store isn't that shape. It runs every 5 minutes (CollectorScheduleDefaults: query_store = 5 min), but its source advances once per Query Store runtime-stats interval (typically 60 minutes, per database). So most cycles legitimately find nothing new, and a streak of 3+ zero-row runs is the normal state for most of every hour.

Fix options (to decide)

1. Exclude query_store (and any other collector whose source advances on its own interval) from the produced-then-stopped rule, the way event and on-load collectors are excluded, through a named predicate.
2. Make the streak time-based for such collectors: the zero-row streak must span more than the source's own production interval (for query_store, more than the longest interval_length_minutes among its databases, plus the collector cadence) before it counts.
3. Keep the count, but require it across the collector's longest source interval.

Option 1 is the smallest. Option 2 keeps detection for a query_store collector that really stops (the #3885 case ran 1,900+ zero-row successes over a fortnight, so it would still be caught). Whichever is chosen, pin it with this issue's hourly shape (a fixture of 12 runs per hour with 9 zero-row runs and a daily productive cycle → not regressed) and with #3885's shape (a real stop → still regressed).

Related: #3885 (the rule and its measured case), #3819 (the sibling "stopped skipping" rule).