Guides
Validation

How to check your ElastAlert 2 rule is configured correctly

Use this checklist before deep troubleshooting. Most alert failures are caused by YAML layout, missing required keys, or destination configuration issues.

1) Validate YAML structure and required fields

  • Issues with YAML spacing/formatting
  • Incorrect syntax
  • Required fields for rules that are missing
  • Two rules with the same name

Run Test only first. It catches parse errors early and confirms that your query returns expected hits.

Below is a misconfigured example: it declares alert: email but does not provide recipients.

name: Log frequency rule
type: frequency
index: loginfo*
is_enabled: false
 
buffer_time:
  minutes: 1
run_every:
  minutes: 1
 
num_events: 30
timeframe:
  seconds: 30
 
alert:
  - "email"

2) Confirm rule type and destination requirements

Each type: has required fields. Mis-spelled keys or wrong indentation usually show up when you run Test only; missing required fields may fail silently or never match.

  • See Rule types for one page per type (any, frequency, spike, flatline, change, blacklist, whitelist, new_term, cardinality, metric_aggregation, spike_aggregation, percentage_match) with full YAML examples.
  • See Destinations for one page per alert: channel (email, Slack, Jira, PagerDuty, webhooks, and the rest) with required keys and examples.

Flatline note: If your timeframe is 10 minutes but your query only looks at the last 10 minutes in a way that never completes a window, you can see odd timeframe_elapsed behaviour. Prefer the examples on the flatline page as a baseline.

3) Check multiple alerters and YAML nesting

You can list several destinations:

alert:
  - email
  - jira
  - slack

Nested alerter settings must stay aligned under the correct list item, or YAML will throw a parse error (often yaml.parser.ParserError with a line number).

4) Verify destination-specific keys (email, Jira, Slack)

  • Email — top-level email: or per-entry overrides; see Email destination.
  • Jira — requires jira_server, jira_project, jira_issuetype, and jira_account_file pointing to a YAML credentials file (not plain text). Jira Cloud uses an API token as the password field.
# jira_acct.yaml (readable only by the ElastAlert process)
user: jira-user@example.com
password: your-api-token

For self-hosted Jira with a personal access token, the file can contain only apikey:... per ElastAlert 2. Full options: Jira destination.

5) Use ElastAlert execution logs for final diagnosis

When Test only or a live run behaves unexpectedly, check execution output in your own Logs stack (written to the elastalert index). In the dashboard, open Diagnostic logs at /logs-settings/logfile for the stack to correlate rule name, errors, silenced matches, and whether alerters ran. See also Overview — ElastAlert execution logs.