How dashboard activity logs differ from the Kibana audit log

Dashboard activity logs and the Kibana audit log both write structured logs about user actions, but they answer different questions.

Kibana audit log

Dashboard activity logs

Answers

Who accessed what, and when

Which dashboards are used, and how well they perform

Built for

Security and compliance teams

Kibana admins and dashboard owners

Tracks

Security-relevant events across Kibana

Five dashboard actions: create, update, delete, view, refresh

Enabled by

Its own setting in kibana.yml

user_activity.enabled: true in kibana.yml

What dashboard activity logs capture

The user activity service records structured events every time a user interacts with a dashboard. Each event captures what happened and to which dashboard, in addition to who did it. Five actions are tracked:

Action

Fires when

Includes duration

dashboard_create

A dashboard is created

No

dashboard_update

An edit is saved

No

dashboard_delete

A dashboard is removed

No

dashboard_view

A user opens a dashboard

Yes, time on the dashboard until they navigate away

dashboard_refresh

A user changes filters or time range, or auto-refresh runs

Yes, refresh duration

Very often, a dashboard_view event also triggers a refresh.

Every event carries the same core fields, with two that appear conditionally:

Field

What it holds

Present on

user.name

Name of the user who performed the action

Every event

user.email

Email address of the user

Every event

user.roles

Roles assigned to the user

Every event

object.name

Dashboard name

Every event

object.id

Dashboard ID

Every event

kibana.space

Kibana space the dashboard belongs to

Every event

client.ip

IP address the request came from

Every event

event.action

Which of the five actions occurred

Every event

event.outcome

Whether the action succeeded or failed

Every event

event.duration

Time taken, in nanoseconds

dashboard_view and dashboard_refresh

error.type / error.message

Error class and message when something fails

Events where event.outcome is failure

How Kibana records dashboard activity

Under the hood, Kibana plugins report events from the browser or server through a core client, and valid events are written to a dedicated logger. No data is sent to a third party; because events are standard JSON logs, you control where they go and how they’re ingested.

What you can do with dashboard usage data

Dashboard activity data answers five operational questions that would otherwise require further investigation:

• Clean up unused dashboards. Filter for dashboards with zero dashboard_view events. If nobody's looking at it, archive it. This is critical for customers who are managing thousands of dashboards. 

• Troubleshoot performance. The event.duration field tells you exactly how long each dashboard load or refresh takes. Sort by duration to find your slowest dashboards.

• Edit history. Every create, update, and delete is logged with the user who made the change. You no longer have to wonder who modified a critical dashboard or when it happened.

• Plan capacity. Identify users running heavyweight queries during peak hours. If one user's auto-refresh is hammering the cluster every 10 seconds, you'll see it.

• Monitor errors proactively. Dashboards throwing errors surface immediately through error.type and error.message fields, so you don’t need to wait for users to report them.

How to enable dashboard activity logs in Kibana

Add two lines to your kibana.yml ( the service is disabled by default):

Events will start flowing immediately using a default JSON console appender. You can customize the output appender and filter specific actions using the same logging configuration schema that Kibana already uses:

Ship these logs into an Elasticsearch index (for example, via Filebeat), and you have a fully queryable dataset of dashboard usage.

How to query dashboard activity in Discover

Once your activity logs are indexed, open Discover and point it at your user activity index pattern. You'll immediately see every dashboard interaction as a structured event, and they’re filterable by action type, user, dashboard name, and time range.

From here, you can quickly answer specific questions like the examples below. 

How many times was a dashboard viewed? 

Type your question in natural language in the Discover query editor, and press Cmd+J to automatically generate the Elasticsearch Query Language (ES|QL) query, as shown below:

Which dashboards had zero views in the last 30 days?

Dashboards with no activity simply don't appear in the logs, so you can't filter directly for zero views. Instead, this query works backward, pulling every dashboard created (and not deleted) in the past year and then checking which of those had zero views in the last 30 days.

Which dashboards took longer than 10 seconds to load?

Note that event.duration is recorded in nanoseconds, so the query converts to seconds before filtering:

Which dashboards are throwing errors, and what's failing?

This query shows dashboards with one or more panels throwing errors during dashboard_refresh events, so you can quickly spot recurring issues and prioritize fixes:

Build a dashboard usage overview with AI chat

We’re planning to add out-of-the-box dashboards along with the activity logs, but in the meantime, instead of manually building visualizations, open the AI chat in Kibana and ask it to create a dashboard from your user activity data. 

The generated dashboard gives you at-a-glance visibility into your most-viewed dashboards, heaviest users, slowest-performing panels, and recent errors; that is, exactly the operational view that large deployments need.

Get started with dashboard activity logs

User activity logs are available in Kibana 9.5. Begin by enabling the service. Then ship the logs into an index, and start building the operational visibility that your team has been asking for. For full configuration details and the complete event schema, see the user activity documentation.

What backward compatibility means for the Kibana Dashboards API

During technical preview, the API shape could change between releases.[1] That's no longer the case. General availability (GA) means:

• Complete backward compatibility. New fields and panel types will be added over time, but existing fields and behavior remain unchanged. Any future breaking changes would be very carefully considered and would only be introduced in a new major stack version.

• Production-ready with full support. The API carries Elastic's full support guarantees. You can safely use it in production environments for automated deployments, environment promotion, and programmatic dashboard management.

New Kibana API endpoints for Tags, Markdown, and Links panels

Elastic 9.5 also introduces a new  standalone endpoint for Tags, which let you categorize and filter dashboards. Now you can manage them programmatically through dedicated CRUD endpoints, making it easier to organize dashboards at scale across environments.

New Markdown and Links panel endpoints are available now in Serverless and will land in the next stack release (9.6).

What panel types does the Kibana Dashboards API support?

The Dashboards API supports all by-value panels in 9.5 (those defined directly in a dashboard, as opposed to library panels saved for reuse). Every supported panel type has a typed, validated schema.

Panel type

Status

XY charts

Supported

Metrics

Supported

Pie

Supported

Gauge

Supported

Heatmap

Supported

Data tables

Supported

Treemap

Supported

Discover sessions

Supported

Controls

Supported

Markdown

Supported

Links

Supported

ML panels

Supported

Observability panels

Supported

Maps

Coming soon

Vega

Coming soon

How to manage Kibana dashboards as code

The Dashboards API enables a full dashboards-as-code workflow: Export a dashboard as clean, diffable JSON, commit it to Git as the source of truth, review changes in pull requests, and deploy the same definition across development, staging, and production. Once a dashboard is managed as code, treat Git as the single source of truth: Changes made directly in the UI are overwritten the next time you deploy.

The main challenge when moving a dashboard between spaces, clusters, or stages is that dashboards reference objects like data views and library visualizations by ID. Because these IDs are auto-generated and differ across environments, a dashboard exported from one environment can point at objects that don't exist in another. There are three ways to handle this, listed here from most to least automated:

• Use Terraform. The Elastic Stack Terraform provider tracks each resource and maps IDs per environment automatically, so references stay consistent as you promote a dashboard from development to production.

• Define by-value Elasticsearch Query Language (ES|QL) panels. The most portable way to build a panel is to define its visualization with ES|QL directly in the dashboard. An ES|QL query reads from the indices you name in it, so the panel carries no external references to data views or library objects. The result is a fully self-contained, portable dashboard.

• Assign matching IDs. If you reference saved objects, like data views or library visualizations, create them with a chosen ID using PUT (upsert) rather than POST (which auto-generates an ID). Use human-readable IDs, like logs-prod, so they're easy to reuse and recognize across environments.

For a detailed walkthrough of these portability patterns and the full dashboards-as-code workflow, see the Manage dashboards as code documentation.

Create a Kibana dashboard with the Dashboards API using PUT

Here's a quick example creating a dashboard with a metric panel using PUT instead of POST to assign a custom ID using the dashboard name (service-health-overview). The same logic works for creating standalone visualizations saved in the library.

Kibana Dashboards API roadmap: Maps, Vega, and standalone endpoints

We're actively expanding the API surface. Maps and Vega panel support is next, adding typed schemas for them. We're also building standalone CRUD endpoints for Discover sessions (beyond their existing support as dashboard panels), Vega, Maps, and Annotations, decoupled from the dashboard lifecycle.

For the full schema definitions, visit the Dashboards API documentation. For Terraform users, the Elastic Stack Terraform provider supports the GA Dashboards API.

Note

1. The core endpoints are unchanged from the technical preview. If you built integrations against 9.4, they work in 9.5. The only breaking changes are two minor ones affecting dashboard listing and duration unit formats, documented here.

ES|QL charts performance and interactivity in Kibana dashboards

How ES|QL Fast mode runs dashboard queries up to 100x faster

For common analytical tasks, like trend tracking, top-host identification, and capacity overviews, trading a small margin of accuracy for dramatically faster results is the right call, especially since not every question needs an exact answer.

Elastic Search 9.4 introduced approximate ES|QL queries as a syntax-only command in technical preview. Now, 9.5 makes approximation GA and adds Fast mode, a UI toggle in Dashboards and Discover that enables approximate ES|QL STATS queries without writing any query syntax. This makes Kibana one of the first tools to offer smart sampling with automatic extrapolation as a simple switch.

Fast mode is an Enterprise-only feature and is off by default. Dashboard authors can save their preferred state with the dashboard, and individual queries can override the toggle with SET approximation=true or false inline.

When switched on, ES|QL STATS queries target a fixed sample size (defaulting to 1,000,000 rows for grouped aggregations and 100,000 rows otherwise) rather than scanning the full dataset. Benchmarks show heavy aggregations running up to 100x faster on large datasets, with results that are typically highlyaccurate, defaulting to a 90% confidence interval. Approximation only applies to STATS commands where results can remain accurate. When accuracy cannot be ensured (such as with small datasets or aggregations like MAX, MIN, or COUNT_DISTINCT), Kibana automatically falls back to exact execution, even with Fast mode enabled.

Further improvements to how charts communicate that results are approximate are coming in future releases.

Click-to-filter and Discover drilldowns for ES|QL charts

Two of the most popular interactions for data view charts are also landing now for ES|QL-based visualizations.

• Discover drilldowns now work on ES|QL panels. When a user clicks a data point or uses Explore in Discover, filters are translated to ES|QL WHERE clauses and Kibana Query Language (KQL) queries are carried over automatically. 

• Click-to-filter also works for renamed fields: if your query renames a column (STATS BY node = k8s.node.name), Kibana now resolves the alias back to the indexed field, so the filter applies correctly.

• Tooltips: When filtering genuinely can't work (for example, because the field was computed entirely within the query and doesn't exist in the index), Kibana now shows a tooltip explaining why, so users know that it's a query limitation.Beyond interactivity, ES|QL layers now have the same Use global filters toggle (gear icon on the layer header) as data-view-backed visualizations. When you turn it off, the layer's query runs independently of dashboard-level filters, just like form-based layers already do. This is useful for reference lines, thresholds, or baselines that shouldn't change when you filter the dashboard. And ES|QL metric charts now support a background chart, matching the styling option already available for data view metrics.

Beyond interactivity, ES|QL layers now have the same Use global filters toggle (gear icon on the layer header) as data-view-backed visualizations. When you turn it off, the layer's query runs independently of dashboard-level filters, just like form-based layers already do. This is useful for reference lines, thresholds, or baselines that shouldn't change when you filter the dashboard. And ES|QL metric charts now support a background chart, matching the styling option already available for data view metrics.

Upcoming releases aim to keep adding the remaining functionality to ES|QL visualizations, such as multilayer support and saving visualizations to the library.

Identify which Kibana panels use an ES|QL variable

Variable controls are among the most popular ES|QL-only features, since they let you parameterize chart queries to switch between fields, time intervals, or groupings without duplicating panels. On a dashboard with many panels and controls, though, it can be hard to tell which visualizations a variable actually affects. In edit mode, you can now click an ES|QL variable control's label to identify all related panels that consume the variable. Variables with no related panels display a warning to make it easier to audit wiring before saving.

Kibana metric and bar chart layout defaults

Metric chart preset layouts and density options

The metric chart appearance panel now offers preset layouts: Top, Middle, Bottom, and Custom. When you pick a template, the layout snaps into place. If you need fine-grained control, switch to Custom.

Metrics used to pack values tightly, which is great for data-dense dashboards but hard to scan when a metric stands alone. Elastic Cloud 9.5 adds a Density style option under Style > Details > Other, with two presets: Compact (the previous layout) and Default (more padding, larger typography). Newly created metrics use Default, and existing saved charts keep Compact until you change them.

Attribute

Compact

Default

Padding

Tight, minimal spacing

More generous whitespace

Typography

Smaller text

Larger text

Best for

Data-dense dashboards with many metrics side by side

Standalone metrics or dashboards with fewer panels

New charts

Must be selected manually

Applied automatically

Existing charts

Preserved until changed

Must be selected manually

Responsive bar chart labels in Kibana

Labels in horizontal bar charts used to grow unchecked, so on smaller screens, a chart with long category names could become unreadable. Bar labels now get a max width and middle-truncate automatically, so the beginning and end of a label stay visible even when the full text doesn't fit. This works by default, with no configuration needed. In 9.6, we’re planning many more improvements to bar charts and labels.

Kibana dashboard controls populated by ES|QL queries

Controls are the most user-friendly way to filter a dashboard, and most dashboards use them. One of the longest-standing requests from users has been the ability to prefilter the values that a control shows. ES|QL queries make that possible and open a much wider set of possibilities, like chaining controls in new ways using variables. Regardless of how the values are populated, controls filter every panel on the dashboard, including ES|QL and data view visualizations.

Controls can now be populated from an ES|QL query instead of selecting a data view field directly. The Create control flyout adds a Select a field / Write a query toggle. You can write an ES|QL query that returns a single column and run it, and then the control derives its options from the result. Queries can reference dashboard variables through the ?variable syntax, enabling flexible chaining between controls.

Coming soon: Progress bar visualization for Kibana tables

A new progress bar visualization type is available in Elastic Cloud Serverless and is planned for general availability in 9.6. Progress bars show a value relative to a goal or maximum, which is useful for many O11y metrics, like CPUs, memory, or Service Level Agreement (SLA) tracking.

What's next for Kibana dashboards and ES|QL visualizations

Upcoming releases will keep pushing on better defaults, improving the ES|QL visualization experience, and adding new chart types. If you have a pain point or a feature request, select Submit feedback in the top menu; we're listening.

How to try ES|QL Fast mode and the new Kibana dashboard features

If you use Elastic Cloud Serverless, you may already be using these changes. Otherwise, upgrade to 9.5, and then create a dashboard or open an existing one. Many updates apply automatically to new visualizations, while layout and style options appear in edit mode. If you aren't on Elastic Cloud yet, start a trial and explore the latest Kibana dashboards there.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.

What's new in Kibana's AI dashboard creation

Capability

Technical preview (9.4)

GA (9.5)

Error handling

No retry on failed ES|QL queries

Automatic retry up to three times with query inspection and adjustment

ES|QL generation cost

All queries routed through the primary model

Tiered model routing, up to 5x cheaper

Time range

Fixed default window

Automatic selection based on data time distribution

Filter controls

Not supported

Automatically added for the most relevant fields

Vega-Lite charts

Not supported

Natural-language creation, including scatter plots, box plots, conditional formatting, custom tooltips

Chart editing

Not supported

Edit existing Vega-Lite panels through natural language

Automatic error recovery for AI dashboard generation

In the technical preview, the agent didn’t retry failed ES|QL queries. In 9.5, it detects query errors and retries up to three times, inspecting each error and adjusting the query before giving up. In practice, this eliminates the majority of empty-panel issues and produces dashboards that render correctly on the first try.

Why is AI dashboard creation cheaper in Elastic 9.5?

Not every step in dashboard generation needs the same level of reasoning. In 9.5, ES|QL generation routes through a lighter model by default and falls back to the primary model only when needed. If your connector uses Anthropic's Claude Opus 4.8, that means 5x cheaper for ES|QL generation across all panels.

Automatic time range selection based on your data

Dashboards are only useful when they show the right window of data. The agent now applies improved logic to pick a time range that makes sense for the data it's querying, unless the user asks for a specific time range. It considers the data's time distribution and adjusts accordingly, whether that means the last hour for a live incident or the last 90 days for a trend analysis, rather than defaulting to a fixed window.

Automatic filter controls on AI-generated dashboards

Dashboard creation now supports controls; that is, interactive filters that let viewers narrow a dashboard by field values without editing the underlying queries. When generating a dashboard, the agent automatically adds controls at the top for the fields most relevant to filter by.

Vega-Lite charts from natural language: Chart types and formatting beyond the defaults

Vega and Vega-Lite support a wide range of chart types and customizations in Kibana. With 9.5, you can build them from plain language instead of writing the code yourself. 

Scatter plots, box plots, and more Vega-Lite chart types

Scatter plots, box plot charts, faceted small multiples, bubble charts, and composition charts (like combining histograms with heatmaps), among many others, are supported by Vega-Lite. A prompt like Show me a scatter plot of response time vs. request size, colored by service name produces a Vega-Lite panel with the right data mappings. They use Kibana's default color palettes to blend with the rest of the dashboard.

Conditional formatting, custom tooltips, and labels on standard charts

Even for chart types that are already native to dashboards, like bar, line, or area, sometimes you need more control than the default capabilities offer. Vega-Lite through the chat fills that gap. Some examples include:

• Conditional color formatting: Color data points above a threshold differently; for example, turning data points in a line or bars red when some metric spikes beyond your Service Level Objective (SLO). Ask the agent something like Turn any points above 500ms red for my line chart.

  

• Custom marks and labels: Add emojis, symbols, or inline text labels to data points for at-a-glance status indicators.

  

• Custom tooltips: Enrich hover states with additional metrics, context, or computed values that aren't part of the chart's axes. Ask something like Add a tooltip that shows total record counts and the % per bar.

  

This also works for editing existing Vega charts. If you have a Vega-Lite panel that needs a tweak like changing a color scale, adjusting an axis, or switching the mark type, describe the change in chat instead of digging into the JSON code.

How we built natural-language Vega-Lite generation in Kibana

Generating a Vega-Lite chart from a sentence is not a one-shot ask the model for JSON prompt. We built a small agentic pipeline that turns natural-language intent into a validated, data-backed chart.

When a request comes in, the agent first determines whether Vega-Lite is the right fit. For Vega-Lite requests, it grounds the visualization in a real ES|QL query against Elasticsearch and then uses a model to generate the Vega-Lite code. Before rendering, the result goes through a normalization layer that corrects the schema and binds the canonical query. It also applies render-safety transformations.

A few design choices make this workflow reliable:

• Typed tool calling: Chart creation is a structured tool invocation rather than free-form Vega-Lite pasted into the conversation.

• Constrained generation: The model generates Vega-Lite code within a defined schema, making the output more predictable and easier to validate.

• Curated examples: Structural patterns, such as faceting, layered marks, and heatmaps, provide guidance without copying the underlying data.

• Execute-and-verify loops: Queries are executed before chart authoring, and validation failures trigger corrective retries for ES|QL generation.

Try AI dashboard creation and Vega-Lite charts in Kibana

To try natural-language dashboard creation and Vega-Lite charts, upgrade to Elastic 9.5 (or start a free trial), and open the chat in Kibana. Then ask it to build a dashboard from your data. For Vega-Lite, try asking for a chart type you've wanted but never built, like a scatter plot or a bubble chart. If the result isn't quite right, tell the agent what to change. It iterates with you.

This requires an Enterprise license. Get started.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.