Summary Tables and Kibana URL generation not working

[Treeefort]

Firstly, I really appreciate all the work gone into this tool! Thank you @jertel and all contributors!

I'm trying to accomplish an alert that will give me an aggregation summary table, along with a Kibana discover URL and neither of these two things are working. I've gone up and down through the documentation and discussions and am still scratching my head. I feel like I've done everything correctly - Clearly I'm doing something incorrectly.

I was originally using Elastalert2 2.20.0 (bundled with CISA's Logging Made Easy) when I first encountered both issues, and have since grabbed a fresh 2.26.0 container from GHCR and set up my same rule in there, and have encountered the same behavior.

The two issues:

• Summary tables only show a single entry, even if there are many matches. I had originally set up the rule to aggregate based on frequency (at least 3 in 1 minute) and have since switched to "any" for testing, and it still only shows a single entry. I've confirmed I'm getting multiple hits and matches before these go alerts go out.
• My discover URL will generate, but it's always missing the pattern ID portion. It generate all the rest of the URL, and if I manually copy and paste the pattern ID into the URL, I get the correct view.

See attached image of example alert:

Here's the entirety of my rule (aside from my email server settings):

type: any
index: logs-fortinet.fortigate*
filter:
  - query:
      query_string:
        query: "event.code: 0100032002"
  - range:
      "@timestamp":
        gte: "now-1m"
#num_events: 3
timeframe:
  minutes: 1
realert:
  minutes: 1

aggregation:
  minutes: 1

generate_kibana_discover_url: true
kibana_url: "https://lme/"
kibana_discover_app_url: "app/discover#/"
kibana_discover_index_pattern_id: 3f64d518-ea02-45b4-9c29-5c72606ee9dd
kibana_discover_columns: [observer.hostname, fgt.user, fgt.srcip, fgt.method]
#kibana_discover_version: "8.18"
#shorten_kibana_discover_url: true

alert_subject: "Alert: Fortigate failed login attempts"

#alert_text_type: alert_text_only
alert_text: |
  <br/><br/><p>At {0}:<br/>Multiple failed Fortigate login attempts within 5 minutes</p>

  <p>Investigate more in Elastic<br/><br/>{1}</p>

alert_text_args: ["@timestamp",kibana_discover_url]

summary_table_type: html
summary_table_max_rows: 20
summary_table_fields:
    - observer.hostname
    - fgt.user
    - fgt.srcip
    - fgt.method

attach_related: true

import: email_alert_config

[jertel]

Regarding 1) ElastAlert 2 debug logs might be helpful. I would like to see it showing multiple matches and then sending out the alert in the same run cycle.

Regarding 2) The screenshot below shows where the index pattern ID is being inserted into the query (2 places, orange arrows). Where exactly are you inserting that same ID to make it work?

[Treeefort]

Thanks for the quick reply!

1. I'll run some more tests and grab the debug logs tomorrow and send them over, about to head home for the day
2. I was pasting it right after discover#/? but now that I'm trying it again, it's not working. I might be mistaken on that point, I'll try that again tomorrow as well.

[Treeefort]

Okay sorry, I'm just an idiot on the discover URL issue. I was using a saved data view ID, not an index pattern ID. Disregard that, I'm just really new to the ELK stack and got confused.

My query didn't do me any favors either - using "range" in the query resulted in no documents appearing after clicking my Discover link. The Kibana timeframe got set to the aggregation time of the alert, and then the query filter set to only show events in the last minute, so nothing appeared. I'll switch back to Frequency and get rid of the range portion of my query:

      "@timestamp":
        gte: "now-1m"

On to the summary table issue, here's a recent test from my ES writeback logs:

And here's another test from the console running with --verbose

INFO:elastalert:Disabled rules are: []
INFO:elastalert:Sleeping for 59.999028 seconds
INFO:elastalert:Background configuration change check run at 2025-09-18 16:12 UTC
INFO:elastalert:Background alerts thread 0 pending alerts sent at 2025-09-18 16:12 UTC

INFO:elastalert:Queried rule Fortigate Admin Failed Login Attempts from 2025-09-18 16:11 UTC to 2025-09-18 16:12 UTC: 3 / 3 hits

INFO:elastalert:Ignoring match for silenced rule Fortigate Admin Failed Login Attempts

INFO:elastalert:Ignoring match for silenced rule Fortigate Admin Failed Login Attempts

INFO:elastalert:Ignoring match for silenced rule Fortigate Admin Failed Login Attempts

INFO:elastalert:Ran Fortigate Admin Failed Login Attempts from 2025-09-18 16:11 UTC to 2025-09-18 16:12 UTC: 3 query hits (0 already seen), 3 matches, 0 alerts sent
INFO:elastalert:Fortigate Admin Failed Login Attempts range 63

Both tests result in the same thing as the screenshot above, a table with a single entry.

[jertel]

The reason you're only getting one match included in the alert is because of the timing configurations within your rule. You have realert set to silence alerts for a full minute after encountering a match. And then you have aggregation set for a 1 minute window as well. So you're defeating the purpose of the aggregation by using a matching realert setting. Try using a realert window that is shorter than the aggregation window:

realert:
  seconds: 1

aggregation:
  minutes: 1

With this configuration you'll get up to 60 matches per alert. Or, remove the realert altogether from both the config.yaml and your rule to get every match.

[Treeefort]

Oh mannnnn I was afraid it was going to be something super simple like this.

In my head, realert was a cooldown between alert notifications, rather than matches themselves. It didn't even cross my radar as something to check.

I removed realert it and it's working fine now. Thank you so much for taking the time to look into my issue Jason!