Improvements to alert generation and storage tracking would help prevent high alert count based performance impacts.

I worked with a customer today who had 6 million alerts on their system. The alert volume had suddenly changed a couple of months ago from <100 alerts per day to over 100k alerts per day, but the customer was unaware of this. 

I would much rather invest in getting alerts to scale vs further complexify self-monitoring just to prohibit customers doing more of what they get value out of. <DarthVaderLackOfScale.jpg>

We should probably do both if some customers are really generating 1M+ alerts in a single day, but I'd like to better understand why this is happening in the first place.

Let's discuss during the next Support interock, please.

Just checked, there is one endpoint to delete an alert by ID, but nothing to delete alerts using a timespan or any other filters. 

DELETE  /api/v3/alerts/{id}  -   Deletes an existing alert

     So deleting millions of alerts using id is not going to be practical

I would like to add one more suggestion. As of today, there is no capability in the product for a user to trim/delete alerts based on criteria like policies, etc. where a Policy might generate a huge number of unexpected alerts. While the only way to reduce the alerts is by reducing the retention, but as in our use case, since 31 Dec 2025, we started seeing +1 million alerts on a daily basis and going up 2.5 million on certain days. 

The SelfMon metrics are absolutely necessary, but then providing the capability to delete what they want based on filters like device/policy/threshold, etc. can enable remove/trim noise from the environment while leaving valid alerts for the customer even for a longer duration as per their requirements.