Rule health: noisy, silent, drifted and expensive rules

Shipping a rule is the start of its life, not the end. Log formats change, services get renamed, a new backup job trips an old threshold. Rules decay. The failure is quiet, which is why rule health matters more than another hundred rules in the library.

This guide splits decay into four classes and checks what each platform documents. The evidence is from public docs and repos read on 2026-11-03, and the matrix on this site lists every cell with its source.

Noisy rules flood the queue and teach analysts to ignore you

A noisy rule fires far more than a human can triage. The damage is indirect: analysts learn to close alerts without reading them.

Documented noise signals are thin. Google Security Operations has a Rule Observability dashboard that shows detection counts and points to tuning with rule exclusions (Google rule performance, read 2026-11-03). That is a count plus guidance, not an automatic flag. Hunters shows leads, alerts and clusters per detector on its detectors page (Hunters detectors, read 2026-11-03). Sekoia groups repeat matches with alert similarity "rather than flooding the alert list" (Sekoia alert similarity, read 2026-11-03).

Elastic is the interesting case. A vendor post describes a monthly pipeline that scores 1,781 prebuilt rules for noise, performance and threat over a 30-day telemetry window (Elastic rule tags post, read 2026-11-03). That scores Elastic's own content, and the docs read name no noisy-rule flag for rules you write.

Anvilogic claims 80 percent less alert noise with continuous tuning. That is a vendor claim with no method on the page (Anvilogic detection engineering page, read 2026-11-03).

Measure noise yourself. For each rule, track alerts per week and the share closed as benign. A rule above, say, 90 percent benign closures for four weeks is a tuning candidate. Those thresholds are a working default from practice, not from any vendor.

Silent rules look healthy and detect nothing

A silent rule is the dangerous one. It runs, or it appears to, and it never fires. The cause is usually a failed query, a disabled dependency or a data source that stopped.

This is the best documented class. Sentinel's SentinelHealth table records whether analytics rules succeeded or failed and why, and the docs describe a query for auto-disabled scheduled rules (Sentinel rule integrity, read 2026-11-03). Elastic shows rule execution status of succeeded, failed or warning, a gap duration, and a "Fill rule execution gaps" action (Elastic monitor rule executions, read 2026-11-03). Google documents rule errors for compilation and runtime failures during test, live runs and retrohunts (Google rule errors, read 2026-11-03). Panther raises a rule error when detection code fails, and a scheduled rule that runs past 15 seconds is terminated (Panther rules docs, read 2026-11-03).

Failure is not the same as silence. A rule can succeed every run and still return nothing because the field it reads is empty. That is the next class.

CardinalOps, now part of Cribl since the 2026-07-14 announcement, claims roughly one in eight detections can fail silently. That is vendor research quoted on a vendor blog, so read it as a claim (Cribl on CardinalOps, read 2026-11-03).

Drifted rules break when a field or schema changes

Drift is the field a rule depends on changing under it. A parser update renames src_ip. A vendor changes an enum. The rule still runs and now matches nothing.

Almost nothing documents this tied to rules. Elastic's Data Quality dashboard checks indices for unsuccessful mappings to ECS, which flags schema problems in the data, not in the rule fields (Elastic Data Quality dashboard, read 2026-11-03). Panther lists Log Classification Errors for logs that fail schemas, again not tied to rule fields (Panther system errors, read 2026-11-03). Google, Sentinel, Splunk, Sekoia, Hunters, SOC Prime, Anvilogic and Detecteam document no drift alert on the pages read.

So build it. For each rule, record the fields it reads. Run a daily query that checks each field is non-null for the data source in the last 24 hours. Alert when it is not. This is the one health check you will probably write yourself.

Expensive rules slow the platform and the bill

Cost shows up as latency, quota, or compute. Elastic's Execution results tab shows how long a rule took to run (Elastic monitor rule executions, read 2026-11-03). Google documents latency metrics and quotas on rule count and complexity. Panther's benchmark command performance-tests one rule against a log type before deploy, with no runtime telemetry described. Sentinel records retry delay per run and no cost figure.

Per-rule cost in currency is not documented by any platform read. Use execution duration as the proxy and sort by it weekly.

Where Mate Security sits

Mate Security says detections are created, tuned or deprecated based on investigation outcomes, and lists tuning, health and coverage as a use case (Mate platform page, read 2026-11-03). Those are vendor claims. The pages read do not say how a noisy, broken or drifted rule is found, which signals are used, or how a rule is deprecated. Mate ranks eleventh of fourteen on the proposed scores. The company announced a Series A of 35M USD on 2026-07-28 (Mate blog, read 2026-11-03). Until the method behind the health claims is published, treat the story as an assertion.

A minimal health pipeline

Run four checks on a schedule. Last run succeeded. Alerts in the last 7 days against the rule's own baseline. Required fields non-null. Execution time against a ceiling. Write failures to a ticket queue owned by a named person.

Checklist

• Every rule has an owner and a baseline alert rate.
• A daily job lists rules whose last run failed or was auto-disabled.
• A weekly job lists rules with zero alerts in 30 days and asks if that is expected.
• A weekly job lists the top 10 rules by alert count and benign closure rate.
• A daily job checks the fields each rule reads are non-null.
• A weekly job lists the slowest rules by execution time.
• Deprecated rules are marked, dated and removed on a schedule.
• You wrote down which of the four classes your platform does not cover.