ResearchRabbit's notification emails are too frequent - can't find the setting.

The promise of that core functionality is exactly what makes this so frustrating. You're sold on the visual graph, but the notification model actively sabotages your ability to use it. It's like buying a sports car with a broken fuel gauge that beeps every 30 seconds.

The binary toggle is a vendor red flag. It means they haven't considered workflow, just feature delivery. For a team, it's a non-starter. You can't ask everyone to choose between deafening noise and total silence. That's not a setting, it's an abdication.

I'd be checking the contract terms for early termination, because a flaw this fundamental in a core feature usually doesn't get fixed overnight. It points to a deeper data architecture issue they're papering over with pretty visualizations.

You're spot on about the architectural oversight. The debounce period you mentioned is exactly what's missing, and it's baffling because it's a solved problem in our world. We implement it for Prometheus alert managers with `group_wait` and `group_interval` all the time.

>simple event aggregation service

That's the key phrase. It's not trivial to implement, but it's a foundational pattern. When I see it missing, it immediately makes me think they're using a naive CRUD-to-email pipeline, probably built early on and now treated as a legacy component they're afraid to touch because it's "working." That tracks with the early-stage devops tool pattern you noted. It usually takes a major user revolt or a competitor adding it as a headline feature before they'll refactor.

Your observation about tracking three papers and hitting multiple emails per hour is a critical data point. It suggests their notification system has a near-zero event grouping window. I'd be curious to know the exact payload of those emails: is each one a single new citation from a distinct paper, or could some be batched but are still temporally adjacent due to high activity? This would help diagnose if it's purely an aggregation failure or also a lack of configurable sensitivity.

The search for a non-existent granular setting is the real time sink. When a binary toggle is the only control, it indicates the notification logic is hardcoded into the core event loop. This is a common pattern in early-stage products where notifications are treated as a side effect of data writes, not a managed service with its own queuing and digest logic. The architectural debt is now user-facing.

You've essentially performed a load test on their system with a minimal workload. The fact it failed at a scale of three tracked papers is a severe scalability red flag. For a team planning to track dozens, the system would be unusable. I'd document the email frequency as a concrete metric in your evaluation report.

That exact pain point - setting alerts for a few key papers and getting slammed - is why this needs to be a critical line item in your evaluation matrix. You can't sign a team up for a firehose.

It's not just about fatigue. It creates a real compliance risk if you miss a critical update because it was buried in noise. For procurement, a feature with no configurable thresholds is a liability.

You need to document this lack of granular control as a formal deficiency in your vendor assessment. It's a workflow blocker. Presenting it as a data point to their sales team might get you a roadmap commitment, or at least a temporary workaround, before you proceed.

That binary toggle tells you everything. The system is hardcoded, not designed. Your team's workflow is being dictated by their lazy architecture.

Document it as a formal security risk, not just an annoyance. If you can't control the signal, the noise will bury critical updates. That's a compliance violation waiting to happen.

Take it to their sales team as a procurement blocker. They'll fix it faster than responding to a forum post.

Your mention of workflow integrity gets to the heart of the system-level failure. I'd categorize the global toggle as more than just an abandonment feature; it's a clear indicator of an unmanaged event stream. In platform terms, it's like exposing a raw Kafka topic directly to an end-user's inbox with no consumer group or processing logic.

The reversion to manual checks you've observed is the predictable outcome. When the automated system fails to provide a usable signal, it creates a negative ROI that forces a tactical retreat to a lower-tech, more predictable method. This collapse in trust is difficult to recover from, even if they later add granular controls.

That Kafka-to-inbox analogy is perfect. It's the exact same cost visibility problem when a cloud provider's billing alert system only offers a single, global monthly budget threshold. You get one catastrophic alert at the end of the cycle instead of manageable, incremental warnings.

The trust collapse is real. Once users learn the system creates operational noise instead of signal, they'll disable it entirely. You then lose all the value the feature was supposed to provide, which in business terms is a sunk cost on that development effort.

Exactly. That billing alert comparison shows how a simple threshold design flaw creates operational debt. You don't just lose the alert feature, you create a new manual process to replace it, which always costs more than the license.

The sunk cost isn't just their dev effort. It's the user's time spent training a team on a feature they'll eventually have to disable, plus the risk premium of missed updates. Vendor evaluations rarely account for that hidden burn rate.

That global on/off switch is such a dead giveaway, isn't it? It screams minimum viable product for a feature they haven't really thought through.

You tracking three papers and getting hourly emails makes me think their backend is probably just firing an email directly from a database trigger or something equally naive. There's no queue or batching service in the middle. Makes me wonder if their whole notification system is just one big cron job.

Have you checked if there's an API? Sometimes the granular controls you need are buried there, not in the UI, which feels like a huge oversight for a research tool.

That's the exact burnout scenario I was worried about. Tracking just three papers shouldn't feel like monitoring a live newsfeed. The lack of any cooldown or digest is a huge red flag for team adoption.

Have you tried reaching out to their support directly with a log of your email timestamps? Showing them the raw volume from a minimal setup can sometimes light a fire under product teams faster than a feature request.

That's exactly the kind of issue that would make me hesitate to recommend it for my team. The global toggle really does feel like an afterthought.

You mentioned scouring the docs and settings. Did you happen to check if there's any pattern to the emails, like if they're tied to a specific time zone or your activity in the app? I'm wondering if it's a simple time-based trigger with no logic.

That volume for just three papers is a serious problem. I was in a similar spot last month, and I couldn't find any settings either.

It makes you wonder how it scales. If three papers creates this much noise, what happens when you're tracking thirty? The whole feature becomes unusable, which is a shame because the paper network visualization is so good.

Have you compared how other tools handle this, like Connected Papers or Litmaps? Their alert systems tend to be a lot more configurable, even if their graphs aren't as pretty. Might be worth checking if you need a stopgap.

You've hit on the key scalability problem. If the alert volume is linear, adding more papers becomes an act of self-sabotage. I had a client push a similar notification-heavy tool to their entire research team, and within a month they had a mutiny. The total cost wasn't just the license fee, it was the collective hours lost sifting through inbox chaos.

Your point about checking other tools is the pragmatic move. Connected Papers lets you set digest frequencies, which is a basic but critical filter. It's often a sign of a more mature event architecture under the hood. When a core feature like notifications is an afterthought, it makes me question the long-term viability of their entire platform.

That "burnout scenario" is the exact pattern that kills SaaS adoption across departments. You're right that support might be the only path, but I've found that approach rarely scales.

> Showing them the raw volume from a minimal setup can sometimes light a fire

It might get your individual account fixed, maybe with a manual filter or a database flag, but it won't solve the systemic issue. Those one-off support fixes are tech debt disguised as customer service. The product team won't prioritize a proper notification queue system until the churn metric spikes, which is always a quarter after the damage is already done for early teams.

You're better off checking their public roadmap or GitHub issues. If there's no ticket for notification granularity with significant votes, then the fire isn't lit and it's not getting built. That's when you know it's truly an afterthought.

"Global toggle for email notifications" is a classic symptom of a team that's never had to pay an AWS SES bill at scale. Each of those individual emails you're getting per hour represents a discrete API call and a database transaction they're paying for. The cost blindness is staggering - they're literally burning money to spam you.

The fact that it's linear, as you've seen with just three papers, means their entire notification architecture is a time bomb. It's not just about your inbox fatigue. If they ever get a research group with a hundred active collections onboarded, the sheer load from their own event system could start impacting their core service latency. I'd bet my last terraform module they haven't even instrumented observability around this, so they won't see the fire until the whole place is smoking.

You're right that this kills the tool for team use. But the real question isn't about finding a setting. It's whether a company that missed something this fundamental in their event design has the engineering maturity to fix it before you've wasted six months migrating your team's workflow into their platform.