Skip to content

fix(spike protection): correct floor calculation explanation #13556

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 1, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/pricing/quotas/spike-protection.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -81,7 +81,7 @@ As mentioned above, our Spike Protection Algorithm is based on the higher of two

### Minimum Event Calculation

This calculation, which is the first step of our algorithm, identifies a minimum number of events, using your quota as a guide. This number takes the maximum of either 500 events or the result of the following formula `(3 \* your quota)/(720 \* number of projects)`. The number of projects is capped at 5 and is used to adjust the floor. The equation represents your project using up three times your overall quota in 30 days if events are continually ingested at this hourly rate, thus flagging the project for a potential spike.
This calculation, which is the first step of our algorithm, identifies a minimum number of events, using your quota as a guide. This number takes the maximum of either 1/10th of the minimum reserved volume quota on the Developer plan for that event type or the result of the following formula: `(3 \* your quota)/(720 \* number of projects)`. The number of projects is capped at 5 and is used to adjust the floor. The equation represents your project using up three times your overall quota in 30 days if events are continually ingested at this hourly rate, thus flagging the project for a potential spike.

### Usage-Based Calculation

Expand Down