Verify an alert against historical logs before you save it
Verify Alert answers one question while you are still editing: if this alert had been running, what would it have done? The panel evaluates your query and condition against logs already ingested and reports how many alerts the definition would have generated over the preceding 24 hours, with the matching logs behind each one.
Use it to catch a definition that is too noisy or too quiet before anyone starts receiving notifications from it.
What you need
- An alert definition open in the alert editor, with a query and a condition set.
- A logs or metric alert type. Both show the visualization; dataset and logs anomaly alerts do not.
- For coverage of the Medium (Monitoring) tier, an archive bucket configured on your account. See Which data tier the visualization queries.
Read the visualization
The visualization runs as you build. It evaluates the definition currently in the editor, not the last saved version, so adjusting the query or the condition updates what you see.
- Set your query and condition in the alert editor.
- Read the graph under the query. It shows the time frames the definition would have triggered in over the window it covers, and how many times.
- Select a point on the graph to see the logs behind it.
Coralogix samples a query returning many series rather than drawing it in full, so a definition grouped by a high-cardinality field shows a subset of permutations. Narrow the grouping or add filters to inspect a specific one.
Which data tier the visualization queries
The visualization reads logs that are already stored, so what it can see depends on which tier those logs are in and whether your account has an archive bucket.
| Archive bucket | Tier queried | Logs covered |
|---|---|---|
| Configured | Archive | High (Frequent Search) and Medium (Monitoring) |
| Not configured | High (Frequent Search) | High (Frequent Search) only |
An account with no archive bucket has nothing stored in the archive tier, so the visualization queries the High tier directly rather than returning an empty graph.
The panel waits for the archive-bucket check to finish before it runs its first query. That check happens as the editor opens, so the first graph you see is already scoped to the right tier and does not need a second run to become correct.
For tier definitions and how Coralogix moves data between them, see TCO Optimizer.
What changed
Two things changed, and they landed together.
Log alerts now show the visualization. Previously the editor rendered it for metric alerts only, so a Lucene, ratio or other log-based definition gave no indication of how it would behave until after you saved it. Log alerts now show the same visualization as metric alerts, and the older collapsible Verify Alert panel it replaces no longer appears.
Coverage extended to the lower tier. The evaluation used to read the High (Frequent Search) tier only, while the alert itself evaluated both tiers. A definition matching logs in the Medium (Monitoring) tier therefore reported fewer triggers than it went on to generate once you saved it, with nothing to indicate that was happening.
| Previously | Now | |
|---|---|---|
| Log alerts | No visualization | Same visualization as metric alerts |
| Tier queried | High (Frequent Search) only | Archive, when the account has an archive bucket |
| Logs covered | High only | High and Medium |
| Agreement with the live alert | Could under-report | Sees the same logs as the alert |
| Without an archive bucket | High only | Unchanged |
For an account with an archive bucket, the visualization and the running alert now evaluate the same set of logs, so the trigger count is a fair prediction of what the alert does.
Why the visualization can still differ from a running alert
The visualization is a prediction, not a replay. Expect these differences even when the tiers line up:
- Verify Alert evaluates a fixed historical window. A running alert evaluates continuously, so it sees data that arrived after your last verification.
- Late-arriving logs are present for the running alert and might be absent from a verification you ran earlier.
- Alerts that group by a field report per group. A verification samples groups rather than enumerating every one.
Limitations
- Dataset alerts have no visualization. They evaluate a selected dataset rather than the indexed store the panel queries. See Dataset alerts.
- Logs anomaly alerts have no visualization. Their condition follows a learned baseline rather than a threshold the panel can replay.
Troubleshooting
The graph is empty.
Work through these in order:
- The field in your query has no data in the selected time range. Widen the range or check the field name.
- The matching logs are in a tier the verification did not query. Confirm whether your account has an archive bucket.
- The account has no archive bucket, so the verification reaches only High (Frequent Search) logs.
The alert count looks lower than expected. Check whether the logs you expect to match sit in the Medium (Monitoring) tier, and whether the account has an archive bucket. Without one, the verification covers the High (Frequent Search) tier only.
Verification fails with an error. Check the query and the condition. A query the editor accepts can still fail verification if the condition references a field the query does not return.