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.

[Angelodaniel]

Hey Team, I reported #81912 a while ago. And I would love to have some kind of default receiver for Spend management as well. If nothing specific has been setup for alerting for that SKU or Project.

[Angelodaniel]

Additionally Developers from a team without admin roles should also be able to see how often they hit this limit Reference
So ideally it's not just visible for higher role members

[vsanse]

This is a very vital thing to have in place, we added some workarounds to get this visibility to devs, but all of those are sort of hacks, would really see this getting addressed as part of Spend Management

[keradus]

even for existing functionalities before Spend Management project introduction

[brianthi]

Completely agree, it's going to be critical for all users to be able to see what rules exist and how those could be impacting the ingestion of their data into Sentry.

[charlax]

(for context: I'm on an enterprise billing with fixed yearly budget)

Thanks for starting this discussion. Really appreciate you looking for feedback.

My org has hundreds of project so what I'm really looking for is some smart default where one project misbehaving (i.e., starting to have 1,000s of errors per minute) does not use all of the budget. This should also apply to slow burns (a project with less active maintenance that starts using too much budget).

Another thing I'd like to be able to do is automatically enable sampling for the whole project (or team?) when such a burst happen. My thinking is that once you get to those level of errors, you probably don't need details on every single one of them.

There should be a notion of smart-by-default budget allocation between projects. For instance, if 10 projects are using replay, one or more projects shouldn't be able to use 100% of the budget, leaving nothing to the other one. There should always be some minimum the other projects can use at any given time (probably not 10%, but something like 1%?).

Alerts are good. It would be best for Spend Management to automatically take action, notify Sentry org owner + project owner + service owners (ideally, email + slack).

A quick piece of feedback: naming those features should be intuitive. "auto-sampling" is transparent. "Spend management", "budget allocation", "auto-spike protection" is pretty ambiguous.

Hope that helps!

[willianccs]

I would like to align my support with the points raised by @charlax, as they address several challenges we are also facing at the company.
In particular, I believe the following concepts are crucial:

• Smart Default Budget Allocation: Ensuring one project doesn’t monopolize the budget in case of unexpected bursts (e.g., thousands of errors per minute) or slow burns. Introducing safeguards (e.g., minimum allocation per project/team) would enhance overall reliability and fairness across teams.
• Automated Dynamic Sampling: Automatically enabling sampling during spikes is a great way to mitigate consumption issues. At those extreme levels of errors, capturing every single detail is usually unnecessary.
• Proactive Alerts and Notifications: Spend management should ideally take action based on usage triggers and notify the Sentry Org Owner, Project Owners, and Service Owners across communication channels like email and Slack.
• Intuitive Feature Naming: I also echo the feedback on having clear and transparent naming conventions (e.g., Auto-Sampling, Smart Budget Allocation, Auto-Spike Protection), as this makes adoption easier across organizations.

These improvements would empower organizations like ours to manage Sentry’s capabilities better while maintaining predictable budgets.

Looking forward to seeing how these ideas evolve.