1. Set a per-project ingest ceiling (Growth and Scale)
On /errors/settings, each project has a ceiling field: the maximum events per minute that project's key accepts, on top of your plan's monthly quota. Leave it blank for no ceiling. It exists for cost and blast-radius control, not abuse protection: a runaway retry loop in one service cannot spend your whole month's quota in an hour.
2. Read the drop counter it produces
Events refused by the ceiling are counted separately from quota and overage drops, as "over this project's ceiling" on the usage lines. That distinction matters because the fix differs: raising the ceiling fixes one, turning on overage or upgrading fixes the others.
3. Set an absolute-threshold alert (every plan)
Beside the ceiling field, set "alert when more than N events in T minutes" for the whole project, or open one issue and set the same rule scoped to just that issue. This is a hard, customer-chosen number, unlike the automatic occurrence-spike alert, which measures a statistical baseline and needs no configuration. Both can fire on the same issue.
4. Understand why it does not re-alert every batch
Once a threshold rule fires, it stays quiet until the rate falls back under half the threshold, then re-arms. Without that, a count sitting right at the line (499, 501, 498, 502...) would email you on every single batch during an ongoing incident.
Go deeper
The full reference lives in the docs: Getting started documentation. Error codes named above are each explained in the error-code reference.