Issues recurring credit grants that have come due, by calling AuroraMeter.Credits.Recurrences.run/1.

Scheduled "7 * * * *" by AuroraMeter.Oban.cron_entries/1: hourly, and at seven minutes past rather than on the hour, because the hour boundary is where every other scheduled thing in a host already is. Hourly is frequent enough that a period boundary is picked up within the hour, and the run is a sequence of no-ops for every tenant whose period has already been granted.

Arguments

%{"limit" => 5_000}, and any of "batch", "max_periods" and "tenant". Ids and scalars only, never a policy and never an amount (architecture-map.md section 6): the entitlement is read from the plan at run time, or from the period's stored policy snapshot, so a job that sat in a queue across a deploy cannot grant yesterday's amount from its own arguments.

Size "limit" so one period's worth of runs visits every entitled tenant at least once. The default of 500 is a safe floor, not a recommendation:

crontab: [{"7 * * * *", AuroraMeter.Oban.RecurringGrants, args: %{"limit" => 5_000}}]

A host without Oban calls AuroraMeter.Credits.Recurrences.run/1 from its own scheduler and loses nothing.