ElastAlert 2

Last reviewed Sep 13, 2026 · 870 words

ElastAlert 2 is the cheapest way to turn a log cluster you already run into a pager: one Python process, about 256 MB of RAM, polling Elasticsearch or OpenSearch every minute and firing a webhook when a query matches. The catch is in that first clause. It does nothing without an Elasticsearch-compatible cluster, and if you are choosing a log stack today, the cluster is the expensive part, not the alerting. Run ElastAlert 2 because the logs are already there, never as a reason to stand up Elasticsearch.

Four rule types cover 90% of real alerts

The project ships a dozen rule types, and I have watched people burn an afternoon reading about all of them. In practice you need four. frequency fires when more than N matching events land in a window (20 failed SSH logins in 5 minutes). spike fires when the event rate changes by a factor against the previous window (3x the usual 5xx count). flatline fires when a query returns fewer than N events (your backup job stopped logging). any fires on every match, which is what you want for "a new sudo user was created" and nothing else, because it will page you for each hit.

The others (new_term, cardinality, change, metric_aggregation, percentage_match) are genuinely useful in a SOC and mostly noise in a homelab. Start with the four above and add one when a specific outage teaches you why.

The whole install is two YAML files

The maintained image is jertel/elastalert2. The original Yelp project stopped in 2020 and this fork, with 1,133 stars, is the one that supports Elasticsearch 8 and OpenSearch. Mount a global config and a rules directory:

services:
  elastalert:
    image: jertel/elastalert2:latest
    volumes:
      - ./config.yaml:/opt/elastalert/config.yaml
      - ./rules:/opt/elastalert/rules
    restart: unless-stopped

The global config names the cluster and the polling cadence:

es_host: opensearch
es_port: 9200
rules_folder: /opt/elastalert/rules
run_every:
  minutes: 1
buffer_time:
  minutes: 15
writeback_index: elastalert_status
alert_time_limit:
  days: 2

writeback_index matters more than it looks. ElastAlert 2 stores its own state (what it has seen, what it has alerted on, what failed to send) in the cluster it monitors, so on first start run elastalert-create-index inside the container to create it. Skip that and the process runs but never remembers, which means duplicate alerts after every restart.

A rule is a third file, one per alert:

name: ssh-bruteforce
type: frequency
index: logs-*
num_events: 20
timeframe:
  minutes: 5
filter:
  - query:
      query_string:
        query: 'program:sshd AND message:"Failed password"'
realert:
  minutes: 30
alert:
  - slack
slack_webhook_url: https://hooks.slack.com/services/...

Test it before it goes live with elastalert-test-rule rules/ssh-bruteforce.yaml, which replays recent data and prints what would have fired. This is the feature that makes YAML rules tolerable: you find the malformed query in the terminal, not at 3 a.m.

The notifier list is the strongest argument for it

Slack, Teams, Discord, Telegram, Matrix, PagerDuty, Opsgenie, email, Gotify, a generic HTTP POST, a local command, and a direct Alertmanager sender. If your household already has a notification path, ElastAlert 2 speaks it without a shim. The Alertmanager target deserves a mention: you can route log alerts into the same Alertmanager that handles your Prometheus rules, so silences and grouping live in one place instead of two.

Where Grafana and Loki win instead

If your logs are in Loki rather than Elasticsearch, this tool is irrelevant; Grafana's alerting evaluates LogQL natively and has the better UI. If you run Graylog, it has its own event definitions on top of the same OpenSearch backend and you probably want those instead. And if the alert you need is "is the service up", a log-derived rule is the wrong instrument; use Uptime Kuma and keep ElastAlert for patterns inside the logs.

The honest positioning: ElastAlert 2 is what you run when you have Elasticsearch or OpenSearch, no Kibana or Graylog alerting licence, and a preference for rules in git over rules in a web form. That is a narrower audience than the star count suggests, and a big one in small ops teams replacing paid Splunk alerting.

The cost is the cluster, not the tool

Budget the 256 MB for ElastAlert and then be honest about the 2 to 4 GB the search cluster wants. On a homelab with one OpenSearch node, run_every: 1 minute across 20 rules is a negligible query load; the thing that hurts is buffer_time set to hours on high-volume indices, which makes every poll scan far more than it needs. Keep buffers short and use realert on every rule, or your first frequency alert will send 60 Slack messages in an hour.

What I'd do

Already running OpenSearch or Elasticsearch for logs: install ElastAlert 2 today, write the four-rule starter set (SSH brute force, 5xx spike, backup flatline, sudo-user any), point every alert at Alertmanager or one Slack channel, and commit the rules directory. Not running either: do not start. Ship logs to Loki, alert from Grafana, and spend the saved RAM on something visible. The broader options are on the monitoring category page.