Hey everyone, been lurking for a while but this is my first post. I'm a junior analyst on our SOC team, and I've been tasked with helping to make our Elastic Security dashboards a bit more actionable for the tier 1 folks. The default ones are great, but we wanted something that combined threat alerts with some of our internal asset context.
I spent the last couple of weeks learning the ins and outs of Lens and the Dashboard JSON structure. It was a bit of a deep dive! I just finished a custom "SOC Overview" dashboard that our team lead actually liked. The goal was to have a single pane showing high-priority alerts, correlated with the top noisy source IPs and a breakdown by our critical asset tags.
I'm sharing the JSON config below in case it's useful for anyone else starting out. I'd also love any feedback, especially on the KQL filters or visualization choices—I'm sure there are better ways to do this.
```json
{
"title": "SOC Overview - Custom",
"description": "Overview of high & critical alerts with asset context.",
"panelsJSON": "[{"version":"8.13.0","panelIndex":"panel_1","gridData":{"x":0,"y":0,"w":24,"h":15,"i":"panel_1"},"panelType":"lens","embeddableConfig":{"attributes":{"title":"","visualizationType":"lnsDatatable","state":{"datasourceStates":{"indexpattern":{"layers":{"layer_1":{"columns":{"col_1":{"label":"Alert Count","data
Nice work on the dashboard. That's solid output for a first dive.
Now, I'm from the dark side of finance, so I have to ask: has anyone run the numbers on what this custom dashboard *costs* to query? Those KQL filters and asset tag lookups can get expensive on Elastic's data plane, especially if this thing auto-refreshes every 30 seconds on a big screen in the SOC.
If you haven't, ask your lead for a peek at the Elastic Cloud bill. Sometimes a well-built dashboard ends up being the most expensive "asset" in the room. Might be worth adding a time-range filter to default to "last 4 hours" instead of "last 24" to keep the scans cheap.
Cloud costs are not destiny.
That's a great point about cost, and it's something a lot of teams overlook when they get into building custom views.
One addition to the time-range advice is to also be mindful of the date histogram intervals on any time series charts you have. An interval of 'auto' can sometimes resolve to a few seconds over a short time window, which multiplies the query cost significantly. Locking it to something like '1m' or '5m' can cut down on aggregation cycles without losing the visual trend.
Beyond the bill, that kind of aggressive auto-refresh can also create contention on your cluster during peak ingest times, which might slow down alerting rules. It's a good habit to build dashboards with performance in mind from the start.
Integrate or die
Good to see your lead liked it. That's a win.
Since you're asking for feedback on the build, take the cost and performance points from the other comments seriously. When you hand this off, you own the operational impact. Get the query cost metrics for this dashboard and baseline it against your standard ones. If it's 5x more expensive to run, you need to know before finance does.
Also, on the asset tag correlation. If that lookup is hitting a separate index, make sure your KQL is using runtime fields or pre-joined data. A live join on every refresh will murder your performance.
—hd
Sharing the JSON config is the easy part. The real problem is that your team lead liked it without asking how you built it.
If you're joining asset data live in KQL, that dashboard will fall over the first time you have a real incident. The refresh will timeout and your tier 1 folks will be staring at a loading spinner. Been there.
You should be building this logic into an index template or an ingest pipeline, not a dashboard filter. Dashboards are for viewing, not for heavy lifting.
Keep it simple