Some customers may want to use RHQ alerting solely as an integration point for external systems.

Or, they may want to use alerting not only for exceptional conditions but also as a "heartbeat" mechanism that is used to report not only unexpected behavior but also to confirm good behavior. For example, generating a alert that only ensures that a resource is reporting normally, and within expected performance.

In this case it may not be necessary. or desirable, for RHQ to accumulate the alert history in the database, once successful notification has occurred.

If an alert definition could include a "transient" or "discard alert after notify" type checkbox, RHQ could avoid the overhead of the alert history storage. This could play well into allowing use cases generating large numbers of alerts without the worry of db or UI flooding.

Perhaps we could even have certain flood limits that would force transient alert behavior after some limit had been reached.