Advanced throttling (meta)

[arisonl]

The following will need their own issues, depending on decisions and priorities.

Abilities to:

• Determine max number of notifications produces by an alert (Observability need)
• Throttle per action (or action group)
• Acknowledge to throttle (customer need and Watcher parity)
• Calendar/time-picker based throttling for example during known downtimes etc.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mikecote]

Is this similar to #66169 or #66055?

[mikecote]

It is worth considering the comments in this duplicate issue: #66169.

[bradquarry]

I have had multiple asks with JPMC teams for a capability within Kibana Alerting that allows for "Maintenance Windows" where all alarms are shut off so that work can be done and dashboards don't light up with all the alarms firing. Basically, for a time window and using TAGS mute all associated alarms for the time window and then unmute them, or optionally specific alerts.

[pmuellr]

I would have expected to see this issue already linked here, but didn't, so referencing it now: #65706

[pmuellr]

Customer request to be able to mute alerts for certain hours of a day. Seems very similar to the bullet item in the original list, of "Calendar/time-picker based throttling for example during known downtimes". Except that I always conceptualize that as someone picking a day or weekend to throttle, over a service upgrade or whatever. To handle select hours over select days over with no end date, I think will require more elaborate "calendaring", in terms of the UI. In terms of data, I think it would essentially boil down to a set of cron-esque entries