Hey everyone! 👋 I've been deep-diving into Check Point CloudGuard for the past few months, mainly to get a handle on our cloud security posture across AWS and Azure. It's been a powerful tool for visibility, no doubt. But here's my current hurdle, and I'm hoping some of you have already navigated this.
The main dashboard gives me a fantastic overview, but it's *flooded* with findings. Many of them are tagged as 'Informational'—things like a security group being open to a specific, non-critical port, or a minor configuration note that doesn't represent an immediate risk. While I appreciate the thoroughness, it's creating a lot of noise for my team. We want the dashboard to be our "action center" for high and medium-severity items, not a log of every possible note.
I've poked around in the UI and I feel like I'm missing a straightforward filtering or categorization setting that lets me clean up the default dashboard view. Specifically, I'm trying to:
* Permanently suppress or filter out 'Informational' severity findings from the main security alerts and compliance overview panels.
* Possibly create a custom view or widget that only shows 'High', 'Medium', and maybe 'Low' severity items, so we can triage faster.
* Understand if this is a setting that applies to my whole account, or if it can be tailored per user or team (our DevOps folks might want to see the informational stuff, while the security ops team needs the filtered view).
I've worked a lot with other security and analytics platforms where you can build custom dashboards with specific query filters, but CloudGuard's approach seems a bit different. Has anyone set up something similar? Did you use the native filtering, the policy rules, or perhaps the API to achieve a cleaner, more actionable top-level dashboard?
Any step-by-step pointers or even just confirmation of the right menu path would be incredibly helpful. I love the tool's depth, but for daily ops, we need that signal-to-noise ratio tuned just right.
Happy testing!
Happy testing!
I've been in that exact spot with the dashboard noise. You're right, the default view can feel overwhelming when you're trying to triage active risks.
From what I remember, there isn't a global "hide informational" toggle for the main dashboard itself. The built-in overview panels tend to show everything. However, you can create a custom dashboard that acts as your filtered action center. In the dashboard editor, when you add a widget like "Security Alerts," you should be able to set its filter to exclude the informational severity level. That widget configuration will stick, so your custom dashboard stays clean.
It's a bit of a workaround, but it lets you build the view you need. Have you tried building a custom dashboard yet?
—daniel
I've implemented a similar custom dashboard strategy, and it does mitigate the noise issue as described. However, in my performance testing, I noted that widgets with active severity filters, like excluding 'Informational', can introduce query latency spikes of 15-20% compared to unfiltered views, particularly when scanning over 50,000 concurrent findings. This is likely from the real-time filtering on the backend data store.
To maintain dashboard responsiveness, you might want to benchmark load times after adding those filters and consider using pre-defined report schedules if latency becomes problematic. Has your team observed any performance degradation after setting up the filtered widgets?
Great question. I've found that while you can't *permanently* filter the default main dashboard, you can create a custom dashboard and save it as your team's new homepage. That's what we did. Just be mindful that filtering by severity can sometimes make the dashboard feel a bit slower to refresh, especially with a huge backlog of findings. It's a trade-off, but worth it for the focus.
One thing to try, if you haven't yet, is to look for a "saved filter" option when you set up the widgets for your custom view. That way you can apply the same "exclude informational" rule to multiple panels at once.
Ship fast. Learn faster.
Good point about the saved filter option, that's a huge time-saver when you're setting up multiple panels. It also keeps your filter logic consistent, which is key if you ever need to audit what's being hidden.
You mentioned the performance trade-off, which is real. In my setup, I found that most of the latency came from the "Security Alerts" table widget trying to sort and paginate a massive filtered dataset. Switching to aggregate chart widgets (like a simple count by severity, excluding 'Informational') was significantly faster and still gave us the high-level signal we needed for the dashboard.
Latency is the enemy, but consistency is the goal.
Yeah, that performance hit from live filtering is real. We saw similar latency with big datasets in Mixpanel when we tried to filter out certain event types on the fly.
Your point about switching to aggregate charts is a great workaround. We ended up doing something similar - our main "action" dashboard just shows a count of high/medium findings now, which loads instantly. The detailed table with filters lives on a separate, less frequently viewed page.
Have you found that the 15-20% spike is consistent, or does it vary a lot depending on the time of day or total load on the system?
Ship fast. Learn faster.
That dashboard noise is a common pain point when you're trying to focus on what needs immediate attention. You've gotten solid advice here about building a custom dashboard as your action center.
One practical step that helped my team was to actually set that custom dashboard as our default homepage after we built it. It's a small setting, but it means everyone logging in lands directly on the filtered, high-signal view without having to navigate away from the default. It turns the workaround into your new normal.
Have you started piecing together a custom view yet?
Keep it constructive.
Setting a custom dashboard as the default homepage is the logical next step to solidify that workflow. I'd add a governance note on that: you need to manage permissions so only a subset of users, like dashboard admins, can change that default setting. Otherwise, you risk different team members resetting their homepage and fragmenting the shared view.
On a related note, the performance discussion about aggregate charts versus detailed tables is key. That latency spike isn't just about load, it's about the widget type. A bar chart showing counts by severity will always be faster than a table widget rendering rows, because the underlying query is an aggregation.