You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Name the Agent job on the Long-Running Query card: nightly maintenance should not read as a mystery twelve times #3497
Second night of live dogfood alerting: at ~05:30Z the nightly index-maintenance window opened
across one production store class and the Long-Running Query alert did its job — roughly a dozen
cards over two cohorts (05:30Z and 06:30Z), each showing an ALTER INDEX ... REORGANIZE or dm_db_index_physical_stats statement past the 30-minute threshold, plus the folded/throttled/
cleared rows the delivery semantics call for. Engine behavior was correct end to end, and the wave
will recur every night, because index maintenance does.
The gap
Each card shows the raw statement text and the runtime. What it does not say is the one fact that
closes the triage: the session running that statement is a SQL Agent job step. The session data
the collector already captures identifies the program as SQLAgent (the job step's session carries
it); the card just never surfaces which job. So the reader gets ALTER INDEX [IX_...] ON [...] REORGANIZE at six in the morning and has to reconstruct "that is the maintenance job, running as
scheduled, merely long" from the statement shape, the hour, and prior knowledge — twelve times.
This is the sibling of #3495 (name the active backup on the High CPU card), and the same contract
applies: annotation, never suppression. A maintenance job running long during its own window is
routine; the same job still running at noon, or an unfamiliar job name on a checkout-adjacent
statement, is a finding. That judgment belongs to the reader, and the reader can only make it in
one glance if the card names the job. The thresholds stay where they are; every card still fires.
Proposal
When a Long-Running Query card's session belongs to a SQL Agent job, append one line to the
card's detail:
Running under Agent job: <job name>, step <n> (<step name>)
The program_name on the session already carries the SQLAgent marker and the job id is derivable
from it (the standard SQLAgent - TSQL JobStep (Job 0x... : Step n) form); resolving id → name is
one msdb lookup the collector can do at capture time or the renderer at fire time. Sessions not
under Agent render exactly as today.
Acceptance shape
A Long-Running Query card whose session is an Agent job step names the job and step; one whose
session is an application connection renders unchanged. The annotation states what IS, never a
verdict — "running under the maintenance job" is the fact; "and that's fine" is the reader's call,
which is the whole point of giving them the fact.
Shipped in the same PR as its sibling: #3511 (squash-merged to dev) — the LRQ card names the Agent job and step per the acceptance shape, with the annotation-never-suppression contract honored, the msdb byte-order pinned, and every degrade arm (permission-denied, deleted job, missing step, non-Agent session) rendering honestly. Closes alongside #3495.
Activity
The High CPU and Long-Running Query cards name the maintenance and th…
erikdarlingdata commentedon Sep 17, 2026
Shipped in the same PR as its sibling: #3511 (squash-merged to dev) — the LRQ card names the Agent job and step per the acceptance shape, with the annotation-never-suppression contract honored, the msdb byte-order pinned, and every degrade arm (permission-denied, deleted job, missing step, non-Agent session) rendering honestly. Closes alongside #3495.
The batched changelog entries for the parallel-lane train: five entri…