When a hunt query becomes a scheduled SIEM detection, what must change in the search?

## Two searches, two jobs The exploratory query and the scheduled detection can express the same intent and still have almost nothing in common as artefacts. A **hunt query** is run once, by the person who wrote it, who is looking at the output. It may span ninety days, wildcard the sourcetype because nobody is sure what the audit stream is called this quarter, carry three joins and a subsearch, and return raw events for eyeballing. Its breadth is its value: it exists to find something nobody has written a rule for yet. Its cost is paid once, and its author will notice if it behaves strangely. A **scheduled detection** runs on a timer, hundreds of times a day, competing for the same search capacity as every other rule, and its output lands in a queue read by somebody who was not there when it was written. Everything about it has to be bounded and boring. ## What changes, concretely **Pin the source.** `index=*` and `sourcetype=*audit*` become `index=db_audit sourcetype=cloudsql:audit`. Wildcards over sourcetypes were tolerable while a human was checking; on a schedule they multiply cost by whatever else lands in those indexes and change meaning silently when a new source is onboarded. **Bound the window and tie it to the schedule.** `earliest=-90d` becomes a window equal to the run interval, shifted back far enough that records arriving late are still inside it — a search running every fifteen minutes might cover from twenty minutes ago to five minutes ago. Get this wrong in one direction and consecutive runs overlap and re-alert on the same activity; in the other, there is a gap between runs that nothing ever examines. **Use fields, not free text.** A bare term such as `customers` matches wherever that string appears; `object=customers` states which field you mean. Free text also makes the rule fragile against unrelated changes in message formatting. **Remove subsearch-backed joins.** A join is materialised on the search head and capped, so a scheduled correlation can silently truncate. Reading both sources in one pass and aggregating with `stats` by the shared key expresses the same intent without an intermediate result set. **Fix the threshold.** During the hunt, the analyst looked at the distribution and said *that one is odd*. The rule needs a number. Deriving a defensible number from real data is its own exercise; what matters here is that the number is explicit in the search rather than living in the author's judgment. **Shape the output for triage.** One row per entity, carrying the evidence: user, client address, database, object, statement count, first and last seen. A rule that emits raw events forces every analyst to reconstruct the picture from scratch at three in the morning, and to re-run the search to do it. ## What the narrowing costs, and why you write it down The exploratory query found a contractor account bulk-reading a customer table through a shared application service account across ninety days and every index. The scheduled version watches one object, on one index, over a fifteen-minute window, above a threshold. It would not have found the same behaviour against a different table, or below the threshold, or spread thinly over weeks. That is not a defect — a rule that keeps the breadth of a hunt cannot run on a schedule — but it is a claim that must be stated rather than assumed. The useful form is one sentence of scope and one of accepted misses: *fires on more than N SELECT statements against the customers object on the db_audit index within fifteen minutes by a single principal; does not see other objects, other data stores, or activity spread below the threshold.* Anyone reviewing coverage later reads that sentence instead of reverse-engineering the SPL. ## The failure mode people forget: the run that never happened A scheduled search that is too expensive does not merely cost money. When the scheduler is saturated, runs are skipped, and a skipped run means that window is never searched — a gap with no alert and no record in the alert queue, because the absence of an alert and the absence of a run look identical from the outside. This is why the narrowing above is a detection concern rather than a budget concern, and why rule cost belongs in the review of the rule. ## Keep the hunt query The hunt does not get deleted when the rule ships. It stays as the wide version you re-run when the rule has been quiet, when the estate changes, or when an incident elsewhere suggests the narrow version's assumptions no longer hold. The pair — one wide and occasional, one narrow and continuous — is the working arrangement, not a stage you pass through.