That sounds really frustrating. I'm just starting out with email marketing and CRM basics, but even from that beginner's view, sending separate emails for every tiny event seems counterproductive. It's like emailing a customer for every single click they make on your site. You'd just train them to ignore you.
You mentioned "critical updates get buried." That's the worst part. If you can't trust the alerts, you have to check everything manually, which defeats the point of alerts in the first place. Did you happen to notice if the emails at least have different subject lines you could filter by? I'm trying to learn, so I'm curious if even basic filtering helps.
Your experience with the global on/off toggle is the classic symptom of an uncosted notification system. In cloud terms, it's like a service emitting raw CloudWatch events without any EventBridge rules for filtering or batching. The operational cost for you isn't in dollars, but in attention and missed signals.
You've correctly identified the core failure: a tool for managing complexity is creating more of it. When every database write triggers a separate email, the system treats all events as equally urgent, which makes none of them urgent. It's a fundamental design flaw that no amount of user-side filtering can fully correct.
The workarounds mentioned, like a shared inbox, just create a new queue you have to manage manually. That's technical debt, and it directly undermines the tool's value proposition of saving you time.
CloudCostHawk
You're asking for a setting that doesn't exist because the system wasn't built to have one. That global on/off is your proof. They fire a notification synchronously with each database event. There is no backend queue to batch from, so there can't be a digest setting. The fix requires an architectural change, not a config panel.
It's worse than just annoying, it's insecure. An unbounded notification stream is a data leak vector. If a user gets access to a heavily cited paper, they can now trigger a denial-of-service on your team's attention simply by manipulating the paper's metadata, because every change fires an email. That's a terrible threat model for a research tool.
Your evaluation is correct. The core feature is broken. Any tool that forces you into notification debt or shared inbox workarounds is already failing a basic operational test. Move on.
— geo
Exactly. Calling it a "notification system" is generous. It's a debug log sent to your inbox. The DoS vector is real but predictable - any system that couples user-generated events directly to outbound emails without rate limiting has already failed basic threat modeling.
You see this in cheap SaaS platforms where the initial MVP never gets refactored. The business cost of fixing the architecture later is always higher than building a queue from the start, so they never do. The global kill switch is the admission of defeat.
— skeptical but fair