Blocking Wait Time fires on one snapshot at 3× the bar or on 3 consecutive collections, not on every snapshot; Long-Running Query gets an opt-out knob seeded from the production read — job-step program prefix, the two NT AUTHORITY logins — applied ahead of the row cap and counted by arm (#3653 A5, Q4 + Q5)

[erikdarlingdata]

Mechanism

Blocking Wait Time (Q4). The alert fired on the FIRST fresh dmv_blocking_snapshots snapshot whose summed wait_time_ms reached BlockingWaitSecondsThreshold and resolved on the first one under it. It now sits behind the shared AlertPersistenceGate as a disjunction: one fresh snapshot at or above 3× the bar fires at once; anything between the bar and that multiple must hold for 3 consecutive collections. Both arms ride ONE gate — the bar handed to ObservePersistenceAsync is one sample when the snapshot clears the multiple and BlockingWaitBreachSamples otherwise — so a 3× fire opens the incident on the same persisted record the consecutive arm would, and the clear that follows is the same clear. The fire prepends a gate item whose Fired By field carries single_snapshot_3x / consecutive_k3.

What makes this arm unlike tempdb's: the collector writes rows only while something is blocked, so a quiet cycle writes nothing. Two breaching snapshots with a quiet cycle between them are two episodes; the arm restarts a partial streak when a breaching snapshot lands more than 1.5 collector cadences after the last one counted (CurrentBlockingWaitResult.CadenceMinutes, the number both adapters already resolved for freshness). An OPEN incident is not restarted by a short gap. A STALE snapshot is a clear (the arm's #1812 rule — it is the collector saying the blocking ended), observed per sweep; a NULL read freezes the gate; disabling the gate is not a clear. The in-memory active flag is gone; the persisted Firing bit under the alert's own metric name in the existing (server_id, metric_name) table is the one "incident open" fact — no rung.

Long-Running Query opt-out knob (Q5). New IAlertEngineSettings members LongRunningQueryExcludedProgramNamePrefixes / LongRunningQueryExcludedLogins. The rule is spelled once in LongRunningQueryExclusions: a program name matches by prefix (case-insensitive — job-step names embed the job id, so only a prefix can name the class), a login matches exactly (case-insensitive — a prefix would let svc swallow svc_owner); no wildcard grammar (* is a character, %/_ are escaped before LIKE), a null session value matches nothing, blanks are dropped on the way in. An excluded session is NOT EVALUATED — not read into the decision, not counted, not fingerprinted — the opposite of a mute, so excluding a paging program resolves the open incident. Applied IN THE READ ahead of LIMIT on both SKUs (a candidates CTE flags each over-threshold row once per arm with the shared ILIKE … ESCAPE '\' predicates, the outer query keeps the unflagged rows under the cap and returns the two counts as scalars over the same CTE), because the sessions the knob names are the longest-running by construction and a post-read filter would let them fill the cap and blind the alert.

Seeded from the production read. The 7-day Long-Running Query population on one large production store fell into four classes:

1. SQL Agent job-step programs (program_name prefix SQLAgent - TSQL JobStep): ~460 sessions a week across 11 single-server jobs, medians 35–62 min → default-excluded by program-name prefix. Anything of theirs that should still page is Name the Agent job on the Long-Running Query card: nightly maintenance should not read as a mystery twelve times #3497's job-naming annotation, not this knob.
2. NT AUTHORITY\SYSTEM / NT AUTHORITY\NETWORK SERVICE logins: the permanent multi-DAY background (~70 sessions across 42 servers, medians 4.8–8.6 days, 300K+ snapshots, CDC-capture shaped) → default-excluded by exact login.
3. The application's admin login: deliberately not excluded — it carries the job wave, but it is also the login real ad-hoc long-runners arrive under; blinding it would hide the second to silence the first, and the job-step prefix already removes its share.
4. Named humans: 3 sessions a week. Never excluded — they are what the page is for.

So the two lists ship as ["SQLAgent - TSQL JobStep"] and ["NT AUTHORITY\SYSTEM", "NT AUTHORITY\NETWORK SERVICE"] (LongRunningQueryExclusions.DefaultProgramNamePrefixes / DefaultLogins). They are defaults, not constants: Lite's App statics initialise to the seeds and the settings.json reader replaces a list only when its key is PRESENT — a fresh install or a file without the key evaluates with the seeds; an operator who empties a box (the Settings window always writes both keys) has cleared that arm for good; "Restore Defaults" restores the seeds. Darling's DarlingAlertSettings returns the seeds — not an empty knob — until the knob's store home lands, so both SKUs evaluate the same population from day one.

The card's receipt, split by arm. The Long-Running Query card gains a knob item — Excluded Count, Excluded By Program Prefix, Excluded By Login, and the entries — so an operator can see the knob working and which default did the work. Counts are sessions (COUNT(DISTINCT session_id) inside the one snapshot the read looks at; the production read's (server_id, session_id, tran_start_time) identity collapses to session_id inside one collection of one server, and a MARS session with two request rows is one session), and a session matching both arms counts once, under the program prefix (the login count is taken AND NOT the program flag), so the two counts sum to the sessions removed.

Evidence (one production store class, 43 servers; one large production store for the knob's defaults)

• Blocking Wait Time: 102 episodes, 97 single-snapshot at ~72 s cadence, including the p99 — 1,509 s across 145 sessions — gone by the next collection. A plain K=3 gate drops exactly those.
• Long-Running Query: 191 distinct sessions ≥ 30 min in 7 days, p90 seen in 6,192 snapshots — permanent background requests no gate can separate from a runaway query. The four-class split above is the 7-day read of that population on one large production store.
• The knob evaluates against the snapshot population (query_snapshots / v_query_snapshots, the rows the arm has always read). collect.long_query_completions is not consulted anywhere in the LRQ alert's path, and no LRQ alert description cites it.

Why this shape

• One gate for both blocking arms (a per-observation bar, not a second gate rule) — AlertPersistenceGate's header asks for one mechanism.
• Cadence-based episode detection rather than counting snapshots inside the freshness window — otherwise three separate one-snapshot flaps inside ten minutes would fire as "consecutive".
• Pre-cap SQL exclusion rather than the excludedDatabases post-read shape — the cap problem above.
• Prefix for programs, exact for logins — the shape of the values themselves; the read found no class a wildcard grammar was needed for.
• Two scalars over one CTE rather than a second read — one statement, one snapshot; Npgsql positional parameters do not survive a batch.
• Seeds live on the hosts, not in the engine: the engine never re-seeds an empty list, because present-and-empty is the operator's decision and the absent/present distinction is a settings-store fact.

What it does NOT do

• Does not gate Blocking Detected (the count gate) — untouched.
• Does not give the knob a Darling store home, Viewer boxes or an MCP surface — that is two text[] columns on config_alert_settings, a migration rung (V135), and one un-landed rung rides at a time (cpu_utilization stores each sample's UTC instant beside its server-local stamp and server_properties stores the engine's time-zone id beside its offset (Darling V134 / Lite v63), so UTC-window readers stop deriving an offset that is an hour wrong across DST (#3653 item 13, Q7 + Q8) #3730's V134 is in flight). PR-B carries the rung, StoreConfigProvider seed/read, the Viewer's SettingsWindow boxes and ViewerDataService.AlertSettings, DarlingAlertReader, and the get_alert_settings / update_alert_settings twins on both SKUs — neither SKU publishes the knob over MCP in this PR because McpAlertSettingsKeyTests derives Lite's payload shape from Darling's source, so the two must move together. Darling evaluates with the seeded defaults meanwhile.
• Does not apply the knob to the PostgreSQL LRQ twin (DarlingWorker.EvaluatePgLongRunningQueryAsync) — stated in the Darling README.
• Does not apply the knob to the High CPU card's maintenance probe (deliberate; a backup under an excluded login is still what burns the CPU).
• Does not touch the long_query_completions collector (default-off by CollectorScheduleDefaults); the fleet-wide empty table is reported separately.
• Does not change the K/N/clear numbers into knobs.

Tests

• AlertEngineTests: 19 blocking-wait pins (3× fires at once and says so; 1.5× silent for two, fires on the third as consecutive_k3; a streak one short that triples fires as single_snapshot_3x; same collection_time ×9 = one observation; quiet-collection gap restarts; 72 s adjacent stays consecutive; short gap holds an open incident; no cadence degrades to freshness-window counting; stale resolves once and writes nothing more; stale from cold writes nothing; stale resets a partial streak; null freezes an open incident; disable is not a clear; suppression advances the gate; restart resumes / does not re-announce; constants pinned to the ruling; Darling README row pinned to the constants). 8 LRQ pins (knob travels normalised; the seeded defaults remove the four-class fixture's background and keep the admin login's ad-hoc query and the human, counts 2/2 with the job-step-as-SYSTEM session counted once; excluded session not evaluated and the card counts it by arm; login exact vs program prefix, * literal; excluding everything resolves; empty knob = no item; knob that removed nothing says 0/0/0; CPU probe ignores the knob).
• LongRunningQueryExclusionsTests (rewritten): prefix / exact truth tables, Classify counts-once rule, the seeds pinned to the four classes (and to NOT containing an admin login), normaliser, prefix vs exact LIKE operands, both-arm SQL with FALSE for an empty arm and operand ordinals, both reads' source pins (two flags, COUNT(DISTINCT session_id), AND NOT, no trace of the single-flag shape), both hosts' seeding and Lite's absent-vs-present rule.
• DarlingAlertReadAdapterTests live E2E (Darling PostgreSQL tests): a four-class snapshot — job step under the admin login, job step running as SYSTEM, NETWORK SERVICE with two request rows, the human — read with None (all rows, 0/0), with Defaults (human only, 2/1), and with the login default cleared (NETWORK SERVICE evaluated again, 2/0).
• DarlingAlertTuningKnobsTests: Darling's seam returns the seeds. LiteAlertForwardingTests: Lite forwards both lists. AlertSettingsControlWiringTests: the two new AlertLrqExcluded*Boxes are loaded, gated, reset and persisted (collection exception named).
• Executed here: 347 Darling.Tests in a mactest harness (including the live E2E against PostgreSQL 18 in Docker); the exact Lite DuckDB SQL text on DuckDB 1.5.5 with the same fixture plus the %/_ escaping and literal-* cases (10/10). Mutation: COUNT(*) without AND NOT fails the live E2E 3 ≠ 1. Red-first: 15 blocking pins red against the pre-gate arm; 3 LRQ pins red with the knob unwired. Lite.Tests: CI is first execution (WPF-hosted).

Partial #3653 — item 6 (Q4, Q5 — Darling store home + MCP twins follow as V135)