Hey everyone, I've been moderating a lot of the Snyk discussions here and this is a recurring theme I've noticed, so I wanted to open a dedicated thread.
I'm working with a fairly large monorepo (several hundred dependencies, multiple services) and the Snyk UI, particularly the "Projects" dashboard, can become almost unusable. Scrolling lags, clicking to see vulnerability details takes several seconds to load, and filtering feels sluggish. It's not my connection—other cloud tools are snappy.
I'm curious if others have hit this scale-related performance wall. Are there specific views (like the Reports page vs. the Project list) that are better or worse for you? Have you found any workarounds, like using the CLI exclusively and only checking the UI for specific high-severity items?
From a community management perspective, this kind of friction can really hinder team adoption, especially for developers who are already pressed for time. If this is a common experience, it's valuable feedback for Snyk to prioritize.
Happy reviewing!
Keep it real.
Nope, you're not the only one. It's the classic trade-off. They've bolted on so many features and scans over the years that the core UI buckles under actual data volume.
My workaround is to treat the UI as a read-only reporting layer. All the actual work - monitoring, PR checks - happens via the CLI and CI/CD. I only log in to approve ignore policies or check the report after a major upgrade. If your team expects to use the dashboard interactively, you're going to have a bad time.
From a community perspective, you're right. Devs will just stop opening it.
SQL is enough
Totally feel this. That "read-only reporting layer" approach is exactly what we've settled into, but it creates a weird gap for newer team members who expect the UI to be, you know, usable for discovery.
I've noticed the API doesn't always mirror the UI's filtering and grouping logic, which makes scripting around the slowness harder than it should be. You end up using the CLI for control, but then you're forced back into the sluggish UI to understand the organizational context or audit trails.
It's like they optimized two separate products that happen to share a database.
APIs > promises
That API mismatch is the killer. You try to script a filter for "active, high severity, in certain folders" and the CLI returns a completely different set than the UI shows. So you're forced back into the laggy dashboard just to reconcile lists.
It trains people to avoid the platform entirely, which defeats the point of paying for a managed service. New hires shouldn't need a tribal knowledge wiki entry titled "How we actually use Snyk, ignore the official docs".
Happened with other tools too. It's a scaling problem, but also a product team not dogfooding their own UI on a real 500+ project org.
Yep, the tribal knowledge doc is the real symptom. We have a "Working with Snyk" page that's basically just that, and it's embarrassing when onboarding someone.
The API/UI mismatch you described forced us to pick one source of truth, and we chose the CLI output for automation. It means we basically treat the paid dashboard as a pretty, slow screenshot for leadership.
I've seen this exact cycle in other PLG tools that outgrew their initial architecture. The backend scales for the API, but the UI framework can't keep up with the live queries.
Another tool to try!