Spend Management at Sentry

[brianthi]

Today we’re excited to open a discussion around Spend Management, a new usage control tool designed to give customers a fine-grained, predictable tool that provides protection against runaway and unexpected bills.

🔍 Use Cases

For developers:

• Don’t lose observability until the next billing period just because of a single bug or an unexpected burst of traffic
• Quickly catch and mitigate bugs or misconfigurations that cause unexpected spikes in spend

For org owners:

• Adopt new products without risking runaway costs
• Allow new teams or projects to use Sentry without worrying about exceeding your budget
• Know exactly how your spend can grow — and stop it when needed
• Apply consistent controls org-wide, or customize by team, project or product
• Add allowances ahead of big launches (Cyber Monday, marketing pushes, etc.) to allow for uninterrupted monitoring

🛠️ How it works

Spend Management is a gatekeeper that allows natural variation and controlled growth, while enforcing a configurable cap based on historical spend. This spend cap will grow proportional to your baseline usage increases. The default limits will cap growth at 20% or $20/week in increased spend.

Out of the box this will be a single organization-wide rule, but admins can also create rules for:

• One or more projects
• Specific Products (errors, spans, etc)
• Project + Product combinations

Key mechanics:

• If your weekly usage grows faster than your settings allow, you’ll get an alert.
• If usage keeps climbing and hits the cap, we’ll rate limit data ingestion or prevent users from using features that consume budget for the rest of the day. We’ll send an alert for this as well.
• The rules reset daily, so if the increased usage is temporary or you’ve made adjustments to your code to accommodate, you’ll be back up and running the next day.
• With any unused quota or spend for that day, we’ll accumulate that quota, with limits, to allow you to absorb short-term spikes without throttling usage for the remaining month.

❓ FAQs

Q: What happens when a Spend Management rule is triggered?

Sentry stays available, but ingestion and enablement of features that cost additional money, like Seer autofixes, are paused/disabled until the next day.

Q: Can I opt out or adjust the limits?

Yes. You can tune limits from 5% to 20% growth per week, or set $-based thresholds. You can also use this functionality only for alerts, so you never lose observability.

Q: What if I know we’ll have a spike in usage?

You can add a manual allowance to your rule’s budget to absorb the spike without pausing usage.

Q: Does Spend Management replace spike protection, spend allocation, pay-as-you-go budgets?

Not immediately. However over time, Spend Management will become the unified system for spend control across Sentry.

Q: Why can’t I set it to 0% growth?

Spend Management needs some flexibility as zero growth prevents any adaptive behavior.

Q: I have hundreds of Sentry projects with new projects every day, will there be easy ways for me to manage all these rules?

Yes. We plan to build in defaults and templates that can be used for new and existing projects.

🙋 We love feedback

Tell us what matters to you, share your thoughts in the comments below:

• Are there any other workflows you’d want Spend Management to support?
• Alerts are key, but can be noisy. What would work best to ensure high signal to noise?
• What are the biggest pain points you have with the current pay-as-you-go model, that you’d expect Spend Management to fix?
• How important is project-level vs org-wide control to you? Which would you use more?
• What’s the most important information you’d expect to see for each rule?
• Where would you expect to find Spend Management settings? Billing, project settings etc

[dcharlton-virta]

we currently build our Sentry environment with each project representing a distinct service and separate DSNs within each project for each environment that the service is deployed to. it sounds like if we were to enable Spend Management at the project level, then abnormal usage in one of our development environments would trigger a rate limiting event for the entire project, cutting traffic to our production environment in addition to the lower environment that was causing the spike; is that accurate, or will Spend Management be able to scope to specific DSNs for spans/error monitoring and only cut off traffic for the key that triggered the spike?

[brianthi]

Hi @dcharlton-virta, thank you for the feedback! You're correct that in our current proposal with project based rules, abnormal usage in one environment will trigger rate limiting for all other environments for the same project.

As we were gathering internal feedback for Spend Management, this request for DSN based rules came up as well. I have noted it in our plans. A question for you, what would be your ideal process in Sentry when configuring DSN based rules?

[dcharlton-virta]

@brianthi our preference is to configure everything through Terraform, so having Terraform resources available to build this out as early as possible would be ideal. I don't really have an opinion on where things should be in the UI.

that said, we likely won't be able to use this feature at all until the DSN scoping has been released. having development environments be able to trigger shutoffs of production traffic is too much of a risk for us to be able to turn this on until the DSN based rules are available.