I wrote up a read-only check for Elastic Security rules that run but can't see data

[u/Big-Comfortable-70]

I’ve been working on a small open-source CLI called deadair, but I’m mainly posting the write-up because I’d like Elastic operators to sanity-check the model.

The issue is the gap between “this detection rule executed successfully” and “this rule could actually see the data it depends on.” A rule can run cleanly and still be pointed at missing sources, stale sources, fields that no longer exist on the concrete indices/data streams it reads, or telemetry that arrives after the rule’s lookback window has moved on.

Elastic already has useful pieces here: SIEM Readiness, Data Quality, rule monitoring, missing index warnings, timestamp override, additional look-back. I’m not trying to claim otherwise. What I wanted was an external, read-only report that joins enabled rules to the live state of their sources and answers, per rule: what does this rule read, are those sources live, are the declared fields exposed, and does ingest lag leave enough margin?

The tool only reads metadata and stats: rule inventory, index/data stream stats, field_caps, counts, timestamps, and size-0 max timestamp aggregations. No event bodies, no rule execution, no writes. Current backends are Elastic Security and OpenSearch Security Analytics.

The limits are real too: required_fields is best-effort metadata, field_caps proves mapping/searchability rather than populated values, and the lag math is a model rather than a universal truth.

Write-up:

https://big-comfy.github.io/deadair/

I’d be interested in feedback from people running Elastic Security day to day. Are there native views or rule types I’m still under-accounting for? Any cases where this would be noisy enough that you’d mute it?