We're pretty similar in a lot of ways. It's definitely a pain point, but from a UX perspective its tough to solve. In theory you could manage a lot of things with the API (most of our UI runs off the API these days).
Even with the limitations, we have many people with hundreds of projects, and the general problems we see are more around notification settings than anything else. The usual suspect is that people are getting too many emails when they either want none, or they want digests.
We are giving this a lot of thought as part of our upcoming infrastructure pass. From my point of view it'd make a lot of sense if you could just have a massive stream of events and sort through them however you want. That causes a lot of challenges so it may not be feasible.
Either way its a problem we're aware of and looking to address. The simplest solution from our point of view is to allow you to configure some kind of organization-wide defaults. That won't resolve the API key constraints, but we don't feel that specifically is a pain point.
I see. What I don't understand is why settings need to be so granular.
For example, our company uses Slack. All notifications go to Slack. There's no need for per-project settings because it's all just one room. At some point we will probably want some projects to go to other rooms, but that's a coarse-grained exception, not something that warrants a per-project setting.
Also, if you need per-person notification settings, then surely that's part of the user's account/profile, not the project. That would be just a single dashboard page with (say) on/off sliders for each project.
In my mind, the data model used by exception trackers (including, it seems, Sentry) is wrong. There needs to be just one stream of events, tagged by things like application name that you can filter on. How those events map to things like notifications and aggregations and rules and source files and teams and so on is completely orthogonal to the stream. Those things then apply to a subset that you can modify dynamically without having to reconfigure the sender.
This is basically how Datadog works. Unfortunately they do service monitoring rather than exception tracking, but certainly lessons can be learned from them.
Hands down the best designed operations product I've used.
Even with the limitations, we have many people with hundreds of projects, and the general problems we see are more around notification settings than anything else. The usual suspect is that people are getting too many emails when they either want none, or they want digests.
We are giving this a lot of thought as part of our upcoming infrastructure pass. From my point of view it'd make a lot of sense if you could just have a massive stream of events and sort through them however you want. That causes a lot of challenges so it may not be feasible.
Either way its a problem we're aware of and looking to address. The simplest solution from our point of view is to allow you to configure some kind of organization-wide defaults. That won't resolve the API key constraints, but we don't feel that specifically is a pain point.