Grafana alert migration must honor query type (Instant vs Range)

[miguel-sanchez-elastic]

Product goal

Operators migrating Grafana alerts should not have to manually fix query evaluation mode after migration. A rule configured as Instant or Range in Grafana should produce a Kibana rule that evaluates metrics the same way — without silent semantic drift.

User problem

Grafana exposes two query modes in the alert form:

Grafana UI	Operator intent
Instant	Evaluate the current value (“WHEN QUERY IS ABOVE N”)
Range	Evaluate over a time window at a chosen Interval / resolution

The migration pipeline currently treats alert queries uniformly and emits a range-style query (step=1m) for both. That causes:

• Instant rules over-fire on stale values that already recovered (Migrated alerts ignore the Instant query type and over-fire on stale data #200)
• Range rules run at the wrong resolution when Interval ≠ 1m (Range Grafana alerts migrate at the wrong resolution (hardcoded 1m step) #209)

Operators see a plausible PromQL expression and threshold, but alert behavior does not match Grafana.

Desired outcome

Source configuration	Migrated behavior
Instant (instant: true)	Single evaluation at rule run time → time=now(), no step
Range (range: true)	Window evaluation at source resolution → derived step= from Interval / intervalMs

Out of scope (separate tracks)

• Reduce / Math / Classic / multi-step graphs → Support Grafana advanced Expressions (Math / Reduce / Resample / Classic condition) #194 (complex expression cases)
• Pending period (for) → Grafana pending period is dropped — migrated alerts fire immediately instead of after a sustained breach #174
• Rule schedule interval → Grafana alert migration drops the evaluation interval — migrated rules always run every 1 minute #173 (closed)
• Reducer semantics (last / avg / min) → Support Grafana advanced Expressions (Math / Reduce / Resample / Classic condition) #194

Delivery breakdown

This epic is satisfied when both child issues are done:

Issue	Scope
#200	Instant alerts → time=now(), no step; no over-fire on recovered metrics
#209	Range alerts → step= derived from Grafana Interval / metadata, not hardcoded 1m

Implementation should read instant / range from the exported Grafana query model when choosing the PROMQL selector.

Success criteria (epic level)

• Instant test alert: metric dips then recovers → migrated rule does not fire on stale breach
• Range test alert with Interval 1s → migrated rule uses step=1s, not step=1m
• Migration comparison/report distinguishes Instant vs Range source rules
• Documentation or skill guidance updated for reviewers: what to check on migrated alert queries

How to validate (QA)

Use a small Grafana alert fixture set:

1. Instant — simple threshold, metric recovers before evaluation → no false alarm after migration (Migrated alerts ignore the Instant query type and over-fire on stale data #200)
2. Range — Interval 1s, 10m window → emitted step matches source (Range Grafana alerts migrate at the wrong resolution (hardcoded 1m step) #209)
3. Regression — neither mode emits the wrong selector for the other mode

Related

• Migrated alerts ignore the Instant query type and over-fire on stale data #200 — Instant query type
• Range Grafana alerts migrate at the wrong resolution (hardcoded 1m step) #209 — Range step / resolution
• Support Grafana advanced Expressions (Math / Reduce / Resample / Classic condition) #194 — Complex expression graph
• Grafana pending period is dropped — migrated alerts fire immediately instead of after a sustained breach #174 — Pending period
• Parent: [META] Phase 3: Broader coverage (main cases) #71