How to diagnose HTTP 429 errors in website analytics

Distinguish a monthly event quota from per-minute rate limiting, inspect the failed endpoint, and avoid mistaking a retry queue for durable analytics delivery.

Start with the response, not the symptom

When a dashboard stops updating, repeatedly refreshing the page is tempting. But an HTTP 429 response means the server is limiting requests; the request may have reached a configured rate limit or a usage quota. Those causes need different fixes. RFC 6585 says a 429 response may include a `Retry-After` header to tell the client how long to wait. The status alone does not tell you which limit was reached.

In WhoVisited, inspect the Network panel and find the request that returned 429. The tracker first calls `/api/v1/bootstrap` to obtain a short-lived ingestion token, then sends event batches to `/api/v1/events`. The response body includes an error code. A `quota_exceeded` response points to the workspace's monthly event allowance; `rate_limited` points to a request-rate limit. Check both the URL and the response body before changing your integration.

Check workspace usage across all its sites

Open Workspace settings and compare Monthly events with the included allowance. The allowance belongs to the workspace, so activity from each connected site contributes to the same monthly total. A staging site can therefore use part of the same pool as production. The Billing page shows the included monthly amount, while Settings shows the current month's recorded usage.

WhoVisited increments monthly usage for newly accepted events. Replaying the same event ID does not add another stored event to that count, but replayed requests still count toward the per-minute request limit. If the monthly allowance has been reached, waiting a minute will not create more room; check the workspace plan and the month boundary shown by the product rather than sending repeated test traffic.

Compare the displayed usage and allowance. Include production, staging and any second website in the workspace when reviewing the total.
Look for duplicate analytics snippets, automatic page tracking plus a manual page_view call, or a component that emits the same event on every render.
Trim tests and development traffic. A separate site keeps reports separate, but does not create a separate workspace event allowance.
Use your application's database or billing records for signups, orders and revenue. Browser analytics is a measurement aid, not an authoritative transaction ledger.

If usage is below quota, check request bursts

A workspace can still be below its monthly allowance and temporarily hit a per-minute limit. WhoVisited rate-limits bootstrap requests per site and event ingestion per site. The ingestion limit counts attempted events in the request batch, including replays, even though duplicate event IDs are excluded from monthly usage. Several open tabs, automated browser checks, or a fast retry loop can create a short burst.

Inspect timestamps and batch sizes in the Network panel. Note whether the 429 came from bootstrap or event ingestion, whether its JSON body says `rate_limited` or `quota_exceeded`, and whether requests repeat on a regular interval. Avoid triggering a full-page reload for every check; pause the test, remove duplicate callers, and then make one controlled visit to see whether the error clears.

WhoVisited includes a `Retry-After: 60` header with 429 responses. Its current browser tracker waits about a minute before retrying after a 429. That delay is a backoff, not confirmation that the underlying condition is fixed. A rate limit should clear when the burst ends; a monthly quota remains reached until the available allowance changes.

Do not assume the browser queue is durable

The tracker temporarily places events in a page-memory queue and keeps at most 100 queued events. On an event-ingestion 429, it returns the attempted batch to that queue and retries after a cooldown. This can help ride out a brief rate limit while the page remains open, but it is not a persistent offline queue: closing or navigating away can end that page's in-memory retry opportunity, and events beyond the queue cap can be dropped. Do not promise visitors or your team that every blocked event will eventually be delivered.

If the failed request is bootstrap, collection cannot obtain a token until bootstrap succeeds. If it is ingestion, check the response code and queue behavior separately. This is why a successful application action must never depend on an analytics request succeeding. Record the business result in your own server-side system first, then send a small analytics event as a best-effort measurement.

Verify recovery with one controlled test

In DevTools, enable Preserve log and filter for `api/v1/bootstrap` and `api/v1/events`. Capture the status, response JSON and `Retry-After` value for the failing request.
Check Workspace settings for monthly usage, then check whether multiple sites or preview environments share that workspace.
Audit the page for duplicate snippets, repeated effect calls, oversized batches or an automated test loop. Stop the source of excess requests before retrying.
After the suspected limit has cleared, make one controlled page visit and confirm bootstrap and event ingestion return successful responses. Then verify the expected page view in the dashboard.
If a 429 continues while usage is below quota and traffic is quiet, save the endpoint, timestamp, response code and error string for support. Do not include visitor payloads or credentials in a support message.

A 429 is a useful clue, not a diagnosis by itself. WhoVisited exposes monthly workspace usage in Settings and returns an error code with rate-limit responses; it does not currently provide a per-site minute-by-minute rate-limit dashboard. Read the tracker troubleshooting guide for other collection failures, and the preview deployment guide for why test traffic still uses workspace quota.

References

For HTTP behavior, see the IETF's [RFC 6585, section 4](https://www.rfc-editor.org/rfc/rfc6585.html#section-4), and MDN's [429 Too Many Requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429) and [Retry-After header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After) references. The product-specific behavior above is based on the current WhoVisited browser tracker, ingestion route, rate-limit helper and workspace settings.