ADR-002 Sentry Spike Protection
Status
⌛️ Superseded (by ADR-008 Sentry Spike Protection)
Context
We do not have good visibility over our organisational usage of Sentry. Teams are free to enable whatever features they see fit within our plan and use it as much as they need. We value this freedom and want to preserve it. At the same time, the event and transaction budgets are set on an organisational level and teams do not have visibility over them. We do not want teams to have to worry about any of this. As organisational admins, we want to know when we are reaching the limits of our budgets so we can act accordingly, either investigating and assisting teams, or sending appropriate communications.
Sentry currently does not have billing or usage alerts. There are only two ways to manage quotas - spike protection and per-key rate limiting. Teams are free to set rate limits as they see fit, and we do not change project setups ourselves.
Spike protection would prevent us from using up a certain amount of our quota in a short period of time and we would also get an alert when it has been activated. After it is activated, Sentry will start dropping all subsequent events. This is not acceptable in our case - the organisation has multiple independent teams within it. After getting alerted we would need to identify which project is causing the spike, contact that team and ask them to look into it. This could take a long time during which Sentry is dropping events for all projects.
It is also possible that multiple teams turning on Sentry at the same time causes spike protection to activate, since it is based on average usage. We do not control when and how teams start using Sentry and do not think this risk is acceptable.
Decision
Spike protection is not a suitable way to manage our quota.
Consequences
We are looking at other options for monitoring quota usage and seeking help from Sentry.