Hi Bina,

1. Via the Generic Ping connector: no.

The connector has no cross-cycle timing logic. Each polling cycle it calculates Cycle Packet Loss (PID 1028) per row and the alarm is raised purely by the alarm template threshold on that parameter. There is no notion of "previous alarm start time" or inter-alarm spacing in the protocol, and adding it would mean a custom fork of the connector. So this is not something to solve at connector level.

2. Event Correlation is the right place, with one caveat.

Correlation gives you the two building blocks you need natively:

• Alarm filter: limit to the Generic Ping element(s) and the Cycle Packet Loss / Ping Status parameter, severity Critical (or whatever severity the 100% loss maps to). Important: also enable "Trigger on single events. Don't maintain active tree status", otherwise repeated occurrences are treated as updates of the same alarm tree and are not counted separately.
• Alarm grouping: add grouping "by table index". Each row in the ping table is one destination IP, so this gives you one independent evaluation per IP endpoint, which is exactly your "same IP" requirement.
• Rule conditions: select "Require situation to occur 3 times in 60 minutes before acting".

That rule already covers your example (10:00, 10:24, 10:48 = 3 alarms for the same IP inside a 60-minute rolling window) and it is fully configurable in Cube, no code.

The caveat: correlation counts occurrences in a sliding window. It does not evaluate the delta between individual alarm start times, so it cannot on its own assert that the gaps are approximately 24 minutes rather than, say, 2 and 55 minutes. In practice 3 ping alarms per hour on one IP is usually already the signal you care about, so it is worth checking whether the plain count is good enough for you.

3. If the exact 24-minute cadence really matters

Extend the rule above with an Automation script action instead of (or in addition to) a correlated alarm. The correlation rule then acts as a cheap pre-filter, and the script does the precise check:

1. The script receives the element ID, parameter ID and table index of the triggering alarm.
2. It retrieves the alarm history for that element/parameter/index over the last 60 minutes.
3. It computes the deltas between consecutive alarm start times and counts how many fall within 24 minutes plus/minus a tolerance (2-3 minutes is realistic, since the alarm start time is bound to the polling cycle, not to the actual event).
4. If at least two such pairs are found, it raises an information event or an external alarm, sends a notification, sets a property, etc.

This keeps all the heavy lifting inside a script you fully control, while correlation handles the filtering, grouping per IP and the 60-minute window.

One suggestion before you build this: a 24-minute cadence that is that regular usually points at a deterministic cause rather than random loss, for example a route flap, a DHCP lease renewal, a firewall session timeout, or a scheduled job on the path. It may be worth correlating the ping alarm start times with the polling interval configured on the element and with logs on the network side. If the cadence turns out to be a fixed multiple of the polling interval, the pattern may partly be an artefact of how the element polls rather than of the endpoint itself.

For the actual implementation, in particular the custom Automation script in option 3, we would advise you to reach out to your Technical Account Manager or to the deployment squad responsible for your project. They have the context on your setup and can pick this up as part of the project scope.