Dashboards
Nothing ships pre-built. What you get is a builder, three starter dashboards and four chart types — plus the sampling limits that make the numbers approximate.
No dashboards ship with the product. A new organisation's dashboard list is empty, and it stays empty until somebody creates one. There is no pre-built security overview waiting for you, and if you have been told otherwise by a comparison table somewhere, the comparison table was wrong.
What does exist is a working builder, three starter dashboards you can create in one action, and four chart types. This article covers those, and it covers the sampling limits that make the numbers on a panel approximate — which is the thing most worth knowing before you put one on a screen in the office.
What a dashboard is here
A dashboard is a named set of panels laid out on a twelve-column grid. Each panel is a search query plus a chart type — the same query language described in Searching your logs, with the same fifteen searchable fields and the same limits. A panel is not a separate reporting engine; it is a saved search with a picture attached.
That has one consequence worth stating plainly: anything you cannot search for, you cannot chart. The metadata vocabulary — countries, command lines, consent scopes — is available to detection rules and not to search, and therefore not to a panel either.
| Type | Needs a break-down field | What it shows |
|---|---|---|
stat | No | A single number: how many events matched. Three columns wide by two rows. |
timeseries | No | Matching events over time. Six by four by default. |
table | Yes | The top five values of the chosen field among the matching events — for example the five addresses producing the most failed sign-ins. |
geo | Yes | Accepted and stored, but it does not render as a map — a geo panel falls through to a bar chart. There is no map. Do not build one expecting one, and note that the geographic coordinate fields it would need are among those the pipeline does not populate. |
The three starter dashboards
An empty builder is only marginally more useful than an empty text box: it still asks you to already know what a good dashboard looks like. So three are offered ready to create, each answering one of the questions a business actually has in its first week. Creating one makes a real, editable dashboard of your own — not a fixed template you are stuck with.
- Sign-in activity
- Who is trying to get in. Failed and successful authentications as two counts, authentications over time, and two break-downs of the failures — by source address and by account. This is the one to create first if you create only one.
- Platform health
- Whether the platform is seeing anything at all. Total events, events at severity 7 and above, events over time, and break-downs by which part of the platform produced them and by category. Its real job is answering has ingestion stopped before you find out the hard way.
- Exposure
- What is leaving the building. Network and file event counts, network activity broken down by destination address, higher-severity events broken down by machine, and a wide timeline across the bottom.
The numbers are a sample, not a total
The same limit propagates to the other two chart types, and it is worth understanding rather than working around:
- A table's top five is the top five of those 500 rows, tallied in your browser rather than by the database. On a busy source that is a top five of the most recent 500 events, which is usually the right shape and occasionally not the right order.
- A timeseries has no fixed window. It buckets between the earliest and latest timestamps among the rows it received, so the horizontal axis rescales itself as data arrives. It shows the shape of recent activity; it is not a last 24 hours chart, and there is no time-range control anywhere in the builder to make it one. If you need a fixed window, put a
timestampcondition into the panel's own query. - A panel whose query fails says so rather than showing a zero. That is deliberate: a zero is a claim about the world, and in that circumstance it would be a false one.
None of this makes a dashboard useless. It makes it a good instrument for noticing change and a poor one for reporting an exact figure. Use panels to see that something moved, then use search to find out what.
Building one
The builder is deliberately not a query box. You choose a widget type, choose what it counts or breaks down by, optionally choose a filter, and name it — and the query is written for you, with a plain-language sentence shown alongside so you can check it says what you meant. Nobody has to type a bracket.
One detail worth praising because it saves real time: the filter values offered in the dropdowns are read out of your own events, not from a generic list. A field picker that offers action and then an empty box has only moved the problem, because you still have to know the value is spelled login_failed rather than failed_login.
Layout is changed with explicit move and resize controls rather than by dragging. That is a deliberate accessibility decision, not a missing feature — drag-and-drop is one of the least accessible patterns on the web, and labelled buttons do the same job for everyone, including whoever is working one-handed on a train.
Reading a dashboard needs the siem:dashboards.read permission; creating or changing one needs siem:dashboards.write. Panels also run searches, so a person who can open a dashboard is reading your security telemetry through it.
Creating a new dashboard asks for a name and drops you straight into the visual builder above — there has never been a JSON field to hand-write here, and there is no such thing as starting from a truly blank canvas either: an empty dashboard offers four Quick panels, one click each, chosen because they are the questions a business without a security team actually opens a SIEM for.
- Administrative changes
- Privileged admin actions in your identity system, broken down by action. Has content from your very first day, even before anything else is connected, because IAM writes to this category on signup.
- Failed sign-ins
- A single stat count of authentication failures.
- Event volume over time
- A timeseries of every event, whatever the source — the fastest way to see whether ingestion is alive.
- Where events come from
- A table of event counts broken down by source module.
Three more limits, stated plainly
Editing a panel that contains an OR loses its filter. The builder reads an existing panel's query back into the form so you can adjust it, and it can only do that for queries built from AND conditions. A panel whose query contains OR opens with an empty filter list, and committing the edit overwrites the query you had. If you have hand-written an OR panel, edit its title and its layout freely and leave its filter alone.
A dashboard is a live view, not a report. There is no scheduled refresh, no emailed snapshot and no export. Panels query when you open the page. If somebody needs a figure on a recurring basis, the honest answer today is a search you run and a note you write, or — for compliance purposes — The evidence bundle, which is built for exactly that and is a different mechanism.
What to read next
- Searching your logs — the query language every panel is built from, and its limits.
- Log retention — how far back a panel can see.