Hourly. Daily. Monthly. At every layer of the stack.

Every send checks every applicable cap. The lowest one binds. So if the Node says 5K/h, the Package says 2K/h, the User override says 1.5K/h, the Campaign says 'inherit' — Mumara sends at 1.5K/h, the User's override. Change any of those layers and the binding cap can change. The model is intentionally simple: take the minimum across all applicable caps. You don't need to think about precedence ordering.

Unlimited. -1 is the sentinel value for 'no cap at this layer'. Use it on Enterprise-tier Packages or for trusted internal Users where you don't want to enforce a numeric ceiling. Empty fields default to the platform-wide default (usually conservative); -1 explicitly disables the cap. The difference matters when Users hit zero limits unexpectedly.

The campaign pauses. Mumara records which layer's cap triggered the pause (visible in the campaign's stats and the activity log). If 'Automatically resume auto-paused campaigns' is enabled in Application Settings, the campaign resumes at the start of the next hour (rolling window). If auto-resume is disabled, the User has to manually resume from the campaign list. Notification settings let you alert the User by email when the pause happens.

Daily is per calendar day in the installation's timezone, resetting at midnight. Monthly is per calendar month, resetting on the 1st. These are wall-clock windows, not rolling — so a User who hits daily at 11:55pm gets new headroom at 12:00am five minutes later. Hourly is rolling, so it's 'sends in the last 60 minutes' not 'sends since the top of the hour'.

Yes — the User's Dashboard shows current-period sending against their cap. Per-User reporting also surfaces how close they're approaching daily/monthly limits. For operators monitoring multi-tenant setups, the Admin dashboard aggregates quota utilisation across Users on each Package — useful for spotting which Users are approaching limits before they incident-out.

Commercial-ESP-only feature on Packages. When enabled, Users can send beyond their monthly quota by drawing down on credits (Enable Credits must also be toggled on). The credits-based billing pattern: meter overage instead of hard-stopping at the cap. Useful when you want to bill per-1K-emails-over-the-cap rather than enforce a hard ceiling. See [User Packages](/campaigns/features/user-packages/) for the Commercial-ESP feature set.

No — you set the per-Node hourly limit explicitly to match whatever rate limit your ESP imposes. The platform doesn't auto-detect ESP rate limits because every ESP exposes them differently (or not at all). Best practice: when adding a new Sending Node, check the ESP's stated rate limit in their documentation and set the Node's hourly limit to ~80-90% of that value. Leaves headroom for the ESP's per-second smoothing.

Drips and Evergreen runs draw against the User's hourly / daily / monthly quotas like any other send. Each can ALSO configure its own hourly speed for finer rate control — useful when a long drip sequence would otherwise burn through the User's daily quota in a single execution. The drip/evergreen rate becomes another cap in the cascade; the most-restrictive still wins.

Every attempted send counts against quota when it leaves the platform — whether or not the recipient eventually opens, bounces, unsubscribes, or marks as spam. The quota meters attempted sends. If you want a bounce-aware throttle, the Commercial-ESP 'stop campaigns at bounce-rate threshold' on the Package does that — auto-pauses campaigns at a configurable bounce rate, separate from the numeric quota.

Warmup is about ramping volume on a new sending domain over days/weeks. Use per-Campaign hourly speed to throttle individual sends during warmup, then ratchet up over time. Some senders also reduce the User's daily limit during the warmup period and increase it as the domain establishes reputation. Both layers cooperate — the per-Campaign throttle handles immediate rate control, the per-User daily limit handles cumulative volume discipline.