Usage & overage
Settings → Plan & usage → Usage this month.
What counts as an event
Section titled “What counts as an event”Every row written to the events table. That means:
| Hit | Counts? |
|---|---|
| Pageview | yes |
| SPA route change | yes — it is a pageview |
Custom event, tracing("…") |
yes |
Declarative data-tracing-event click |
yes |
| Outbound link click | yes |
tracing.revenue() |
yes |
tracing.identify() |
no — traits are not events |
| The time-on-page flush | no — it tops up an existing pageview |
The identity probe, GET /c/:key |
no |
| A hit dropped as a bot, an excluded IP or an excluded path | no |
| A confirmed payment from a webhook | no |
| API reads and CSV exports | no |
The month
Section titled “The month”Events are counted across every site on the account, for the current calendar month in UTC — regardless of any site’s own timezone. A site’s timezone changes its reports, not its bill.
The counter resets at 00:00 UTC on the first of the month. The panel shows the exact reset date.
What the panel shows
Section titled “What the panel shows”| Figure | How it is computed |
|---|---|
| Used | Events this month across the account |
| Quota | The account’s own quota if one is set, otherwise the plan’s included events |
| Percent | used / quota, capped at 100 for the bar |
| Projected | used ÷ days elapsed × days in month — a straight-line extrapolation |
| Days elapsed / remaining | Position in the UTC month |
| Overage blocks | ceil((used − quota) / 100,000), never below zero |
| Overage cost | blocks × the plan’s rate |
| Projected overage | The same two, against the projection |
| Top sites | The eight busiest sites this month, so a spike has a name |
The projection is linear and knows nothing about your weekly shape. Early in the month it swings hard; by the second week it is usually close.
Overage
Section titled “Overage”Billed per 100,000 events, part-blocks rounded up.
| Plan | Rate per 100k | Past the allowance |
|---|---|---|
| Hobby | — | Collection stops until the month resets |
| Pro | $2.00 | Metered |
| Business | $1.00 | Metered |
| Enterprise | agreed up front | Metered at the agreed rate |
Worked example on Pro: 500,000 included. 612,000 used →
ceil(112,000 / 100,000) = 2 blocks → $4 on top of the $9 plan fee.
Overage is reported to Stripe as a metered event. A scheduled job — hourly is plenty, since the meter only has to be right by the time the invoice is drawn — reports the delta in blocks since the last run, because a Stripe meter sums what it is given. The ledger of what has already been reported is kept per account per month, so a crashed run repeats at most one block and a double run reports nothing twice.
It is best-effort by design: a failure costs metered revenue for an hour, and never costs a customer their dashboard.
Reducing usage
Section titled “Reducing usage”- Exclude paths you do not report on — admin, previews, health checks.
- Turn off outbound tracking if you do not read it.
- Do not fire an event per keystroke. Fire one on submit, with properties.
- Exclude your own IP, or set
tracing_disabledin the browsers your team uses. - Delete sites you no longer collect for — a deleted site’s future traffic stops, since its key no longer resolves.