Understand workspace allowances and reset times

Allowances by event plan

These are workspace totals, shared across websites and people. Annual billing uses the same allowances. Referral and badge bonus events do not increase these operational allowances. Counters reset on the UTC calendar hour, day or month, rather than your subscription renewal date. When an allowance changes, current usage carries forward. A workspace already at its revised allowance waits for the normal reset; activity is preserved and no extra charge is made.

Email delivery

Settings → Email reports & alerts shows used deliveries, the allowance and its reset date. Each recipient counts as one delivery, including tests and attempted sends. Weekly reports, sale summaries, selected-goal alerts and spike alerts share this allowance. Security, login, billing and support messages do not use it.

When the allowance is used, report and alert emails pause until the next UTC month. Activity remains available in the dashboard. Emails are not a complete activity export and paused notifications are not guaranteed to be replayed. Sale and goal emails group recent activity rather than sending a separate email per event. Checks rotate between websites when the workspace is busy. Workspaces share up to 96 notification checks per day on Free and 10,000-event plans, 288 on 100,000 events, 480 on 200,000 events and 960 on larger plans. Each website can be checked at most once every 15 minutes.

Refresh reports

An identical report can reuse a snapshot for up to five minutes on Free and 10,000-event plans, and one minute on larger plans. The live activity view uses a one-minute snapshot. Relative dashboard periods use the start of the current refresh interval as their snapshot time. Explicit calendar dates, filters, attribution settings and cursor pages remain separate selections; refreshing never substitutes another selection's figures.

Cache hits do not consume another fresh calculation. All database report reads, including cached reads and supporting spend reads, share an additional request allowance of five times the fresh-calculation limits per hour and month. For the 10,000-event plan this is 600 requests per hour and 15,000 per month. The 200,000-event plan includes 3,000 requests per hour and 60,000 per month; the 1-million-event plan includes 7,500 per hour and 175,000 per month. One dashboard refresh can require several reads. Reaching either request limit pauses reads for the rest of that UTC window. Repeat reads use a small validation check when the app server still holds the same snapshot. Otherwise the report is delivered again. Delivery reserves the full serialized database snapshot size for each read, including supporting spend reads, with a minimum of 256 bytes for a retained-copy check. This reservation still counts when an unchanged response body is omitted, so the allowance works consistently across app servers and clients. It is not the size of the visible table or a downloaded CSV. Unchanged dashboard responses also avoid sending the same report body to your browser again. Every refresh still checks your current access; changed, expired or erased snapshots cannot be reused. A single report response is limited to 16 MB. Very large reports need pagination or a shorter date range.

At a calculation limit, existing cached selections can still be read while valid and within the delivery allowance. At the delivery limit, new report responses wait until the next UTC month. Already loaded reports remain on your device. REST and dashboard requests return HTTP 429 with Retry-After; MCP and CLI callers receive the corresponding error. Wait before retrying. Changing keys or reconnecting an app does not reset usage.

Refresh integrations

Manual historical payment imports, connection setup checks, ad-cost imports, CRM snapshots and background subscription sync share the daily refresh allowance. Setup and its initial import can use separate slots. A connection can start the same kind of refresh once an hour. Failed attempts also count, so repeated provider errors cannot create unlimited work.

When a refresh must wait, saved reports and imported records stay available. Background jobs retry on their regular schedule; subscription sync keeps its saved cursor. Manual requests explain the next available time. Normal verified payment webhooks and event collection continue under their existing collection rules.

Slack and webhook alerts

Free and 10,000-event plans include 200 Slack or webhook delivery attempts per UTC month, shared across websites. The 100,000-event plan includes 1,000; the 200,000-event plan includes 2,000; plans from 500,000 events include 5,000. The existing duplicate-visitor checks remain. At the allowance, leads stay in the dashboard and delivery becomes available again next month.