There is no endpoint that reports how much of a plan's allowance an account has consumed. Of the 138 paths in the public OpenAPI spec, none covers billing, usage or quota, and /v1/account-usage, /v1/usage, /v1/limits and /v1/subscriptions all return 404.
The account object does carry freePlanQuotaHitNotificationSent, freePlanQuotaNotificationWarningSent and freePlanStoppedRunningChecksWarningSent, but those are free-plan notification flags and they are sticky — they record that an event happened once, not where the account stands now. On a paid plan they keep reporting a threshold crossed under the previous plan, which is worse than absent, because it reads like a current figure.
So the only way to answer "how much of our allowance are we using?" is to enumerate every check, read its frequency, its location count and its runParallel setting, and derive the run rate by hand. We do exactly that, and it is fragile in a specific way: multiplying cadence by location count is wrong whenever runParallel is false, because the check is round-robin and one cycle costs one run rather than N. Getting that backwards moved our own estimate from 18% to 54% of the browser allowance, and only a separately observed 24-hour run count showed which was right.
Request: GET /v1/usage returning runs consumed per check type for the current allowance period, the allowance, and the period boundaries. Everything needed to answer it exists on your side and is shown in the dashboard. Anyone managing checks as code is currently reimplementing your meter from configuration, and quietly getting it wrong.
Please authenticate to join the conversation.
In Review
💡 Feature Request
About 23 hours ago

Markus
Get notified by email when there are changes.
In Review
💡 Feature Request
About 23 hours ago

Markus
Get notified by email when there are changes.