## Context

First big step toward Alerting feature

## Description

Follows: #3528

* Every time an event is received, we insert a SubscriptionActivity in
the db, unique per subscription
* Every 5 minutes, we recompute `current_usage` for all active
subscription
  * If org has progressive billings, we check the thresholds
* If org is using alerting, we'll check the alert at the same time
(later
* Stop using `lifetime_usage.recalculate_current_usage` but the job
keeps looking at this column until there are not more jobs to process

---------

Co-authored-by: Vincent Pochet <vincent@getlago.com>

## Context

First big step toward Alerting feature

## Description

Follows: #3528

* Every time an event is received, we insert a SubscriptionActivity in
the db, unique per subscription
* Every 5 minutes, we recompute `current_usage` for all active
subscription
  * If org has progressive billings, we check the thresholds
* If org is using alerting, we'll check the alert at the same time
(later
* Stop using `lifetime_usage.recalculate_current_usage` but the job
keeps looking at this column until there are not more jobs to process

---------

Co-authored-by: Vincent Pochet <vincent@getlago.com>

…alerts (#3690)

## Context

We're adding Alerting feature, see #3528, #3535, #3554, #3600

## Description

We introducing 2 new types of alerts:
* LifetimeUsageAmount: to define alert based on lifetime total usage
* BillableMetricUsageUnits: same as BillableMetricUsageAmount but with a
number "used units" instead of currency amount.

Creating a new alert is essentially creating a new child class of
`UsageMonitoring::Alert` and implementing `find_value`. 🙌