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.

Why upgrade to Redux Toolkit v2?

RTK v2 was released in late 2023. That's nearly three years of running on a major version behind in one of the most widely used state management libraries in the JavaScript ecosystem. It reflects how hard this upgrade is in a codebase of Kibana's size. A previous attempt tried the big-bang approach and stalled when the real scope became clearer. 

So what does v2 actually bring? It ships alongside Redux core 5.0, React-Redux 9.0, Reselect 5.0, and Redux Thunk 3.0. React-Redux 9.0 requires React 18 and drops the useSyncExternalStore shim that v8 carried for React 16/17. Since Kibana already runs React 18, upgrading sheds legacy compatibility code and keeps Kibana on the actively maintained Redux majors.

RTK v2 also brings genuinely useful new features, including inline selectors in createSlice and opt-in inline async thunks through a customized buildCreateSlice setup, along with a combineSlices API with slice reducer injection for code splitting. That last one is particularly interesting for Kibana's plugin architecture where lazy-loading is the norm.

How Redux is used across the Kibana monorepo

Before diving into the solution, it's worth understanding just how varied Redux usage is across Kibana. A full audit of the codebase (tracked in #239863) revealed several distinct camps:

Pattern

Plugins and packages

What the migration needs

Redux Toolkit v1

Discover, Lens, Synthetics, Security Solution

Full v1 to v2 migration

Plain Redux v4

Canvas, Maps, Index Management, Cross-Cluster Replication

redux-v4 alias only, no RTK migration

Kea

Enterprise Search (150+ files), Content Connectors

react-redux-v7 alias, no RTK migration

redux-saga

Synthetics, Graph, Uptime

Store setup only, saga is version-independent

typescript-fsa

Security Solution data-table package

Out of scope

Types and single imports

Expressions, Monitoring

Alias swap only

Plugins such as Discover, Lens, Synthetics, and Security Solution use RTK v1 APIs,including createSlice, configureStore, createAsyncThunk, and createSelector. These are the ones that actually need the v1 to v2 migration. But even here, complexity varies wildly. Lens uses stand-alone getDefaultMiddleware (removed in v2) and PreloadedState (also removed). Security Solution is the largest consumer at 300+ files, mixing modern RTK with legacy plain Redux patterns.

Canvas, Maps, Index Management, Cross-Cluster Replication, and several others still use plain Redux v4via createStore, combineReducers, applyMiddleware, and connect, which are classic patterns from the pre-RTK era. These don't need RTK migration at all since they're not using it  in the first place, but they do need the redux-v4 alias since the default redux package is now v5.

Enterprise Search and Content Connectors use kea, a Redux abstraction layer with its own logic builders (kea(), useValues, useActions). There are more than 150 files in Enterprise Search alone. RTK migration isn't applicable here, since kea is its own world. But it does depend on react-redux v7 under the hood, which is where the bundler tricks come in.

Synthetics, Graph, and Uptime use redux-saga for side effects. Saga integration is actually independent of the RTK version, but these plugins need their store setup migrated.

The Security Solution data-table package uses typescript-fsa and typescript-fsa-reducers instead of RTK entirely, with its reducer embedded into Security Solution's main store, and isn’t part of the RTK migration at all.

The Expressions plugin only imports shallowEqual from react-redux, and Monitoring only imports types. These just need an alias swap.

Asking every team to migrate simultaneously was a nonstarter. The breaking changes in RTK v2 include stricter type checking and removed APIs, like enableES5() from immer, getDefaultMiddleware and PreloadedState gone entirely, AnyAction replaced by UnknownAction, and behavioral changes in how middleware is configured.

Running Redux Toolkit v1 and v2 side by side

The solution was to flip the typical migration pattern on its head. Instead of keeping the default imports on v1 and introducing v2 under aliases, the default package names (for example, @reduxjs/toolkit, react-redux, and redux) now point to v2. The old versions live under versioned aliases:

• redux-toolkit-v1

• react-redux-v7

• redux-v4

• immer-v9

• reselect-v4

• redux-thunk-v2

This is npm's alias syntax. "react-redux-v7": "npm:react-redux@7.2.8" installs the old version under a different name. Both versions coexist in node_modules without conflicts.

The insight here is that all existing code in this pull request (PR) was moved to v1 aliases. Every import { useSelector } from 'react-redux' became import { useSelector } from 'react-redux-v7'. That's ~1,100 files touched, but the vast majority (~1,000) are mechanical one-liner import swaps. When a team is ready to migrate to v2, they switch back to the default import names. Once all v1 aliases disappear from the codebase, the old packages can be removed entirely.

This avoids the alternative, where v2 imports would end up under nonstandard names permanently, leaving nonstandard imports in the codebase for the long term.

Serving both versions through the bundler

Getting two versions of the same library to coexist at runtime is where things got interesting. Kibana uses kbn-ui-shared-deps-npm to bundle common dependencies as shared webpack externals. This needed to serve both the new v2 packages and the v1 aliases so that both are available at runtime.

Pinning @elastic/charts with yarn resolutions

Then there's @elastic/charts. It depends on RTK v1 internally and can't just be upgraded independently since it's an upstream package. Yarn resolutions pin its nested dependencies to v1 versions:

A NormalModuleReplacementPlugin in the shared deps webpack config detects when an import of immer, @reduxjs/toolkit, redux, react-redux, or reselect originates from within @elastic/charts and redirects resolution to the nested v1 copies. This ensures that @elastic/charts resolves to its compatible v1 dependency set.

Keeping Kea on React Redux v7 with webpack externals

The kea library was another fun case. It declares react-redux as a peer dependency (>= 7), so without special handling its imports resolve to Kibana's default v9 package. The migration keeps Kea consumers on react-redux-v7, so Kea must use that same React context. The fix uses function-based webpack/rspack externals that skip externalizing react-redux when the import comes from node_modules/kea, combined with a NormalModuleReplacementPlugin that rewrites it to react-redux-v7. This ensures that kea uses the v7 React context that matches the <Provider> wrapping its consumers.

Both the webpack (kbn-optimizer) and the rspack (kbn-rspack-optimizer) configs needed these changes, with a shared isKeaReactReduxImport helper extracted to keep the logic consistent.

Using an ESLint rule to prevent cross-version imports

With two versions available, accidental cross-version imports are the biggest risk. A new @kbn/imports/no_redux_toolkit_v2_imports ESLint rule catches any import of the v2 default packages (such as @reduxjs/toolkit, react-redux, or redux, among others) in code that hasn't been migrated yet. It even auto-fixes them to the v1 aliases for file imports and Jest mock paths.

The rule is scoped via an override in .eslintrc.js to the ~36 plugin and package paths currently using v1. When a team migrates, they simply remove their path from the override list. This clean, self-service approach requires no coordination.

Why mixing React Redux v7 and v9 breaks the context

This is worth calling out because it's an easy failure mode to miss during an upgrade. react-redux v9 and v7 create separate React contexts. If a component tree has a v9 <Provider> at the top but a child component calls useSelector from v7 (or vice versa), React-Redux cannot find the matching context. In development, it throws an error explaining that the component must be wrapped in a matching <Provider>; in production, the missing context causes a runtime error when the hook accesses the store.

This means that each plugin needs to be explicitly pinned to one version. Shared packages that use react-redux can only be consumed by code on the same version, since mixing isn't possible. This is a constraint that makes the migration inherently per plugin rather than per file.

Migration batches: What can move independently

The dual-version setup gives every team a clear path forward, and the dependency graph analysis from the tracking issue identified natural migration batches:

• Batch 1: Independent, self-contained stores. Packages like kbn-coloring, transform, timelines, and expandable-flyout have fully internal Redux stores with no types leaking through their public APIs. These can be migrated independently by their owning teams, with minimal risk.

• Batch 2: Coupled packages. Some packages share RTK types across boundaries and must migrate together. The machine learning (ML)/artificial intelligence for IT operations (AIOps) chain is one example: @kbn/ml-response-stream exports a streamSlice (a createSlice return value) that @kbn/aiops-log-rate-analysis embeds directly into its configureStore. Migrating one without the other causes type mismatches between v1 and v2 slice types. Similar coupling exists across the Lens ecosystem. The Lens plugin depends on @kbn/coloring (which has its own RTK store), @kbn/lens-embeddable-utils, and @kbn/lens-common, while itself being consumed by 40+ packages and plugins across chart expressions, visualizations, Maps, Canvas, and observability plugins. Whether Redux types leak through a package's public API determines if it can be migrated independently or needs coordination. kbn-coloring's store is internal to its React components so it's safe to migrate alone, but other coupling points need careful analysis.

• Batch 3+: The big ones. Discover, Security Solution, and Lens each have their own migration timelines. Security Solution's 300+ files and mix of RTK with plain Redux v4 and typescript-fsa make it the largest effort, but the different patterns can be addressed independently. Lens has the trickiest v2 breaking changes around middleware configuration; stand-alone getDefaultMiddleware and PreloadedState are both removed in v2, and it has four custom middleware files with complex typing.

Beyond the batched migrations:

• Deprecated features can stay on v1 aliases. When the feature is removed, the v1 imports disappear through code deletion, without any migration work.

• Plain Redux v4 plugins (Canvas, Maps, and others) are entirely out of scope for RTK migration. They'd benefit from modernization, but that's a separate initiative.

• Kea plugins need react-redux-v7 to react-redux alias updates eventually, but no RTK migration. The longer-term question (whether to keep Kea or migrate to RTK v2) is a separate decision.

• The dual-version approach adds measurable bundle overhead during the transition. It’s a trade-off but is acceptable for the migration period.

Lessons for other large monorepo upgrades

The ESLint rule turned out to be the linchpin. Without automated enforcement, aliased imports would drift back to default names within weeks. With it, the migration state is visible in the paths listed in the override. As of the initial PR, zero files import from @reduxjs/toolkit v2. Every RTK usage goes through the redux-toolkit-v1 alias. That's the starting line.

The preparation work also reached beyond import paths. Jest mocks referencing react-redux needed updating to react-redux-v7, as did Storybook previews, test helpers, and ambient type declarations. Multiple rounds of node scripts/eslint_all_files --no-cache --fix caught the mechanical cases; the remaining cases needed manual fixes.

If you're facing a similar major dependency upgrade in a large monorepo, the pattern of giving the new version the default name and the old version an explicit alias is worth considering. New code naturally uses the current version, while older usage stays visible and trackable until it reaches zero.

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.

Every year, natural disasters force emergency managers, military commanders, and public safety officials to make high-stakes decisions in compressed time frames. These decisions traditionally rely on phone trees, spreadsheets, and institutional knowledge spread across dozens of people. The coordination overhead alone costs critical time.

This post demonstrates how Elastic can power a responsive, agentic coordination system for disaster response that detects a threat, reasons through the logistics, and takes action automatically. To make it concrete, we built a simulation: a fictitious Category 4 hurricane threatening the Hampton Roads coastline triggers the automated relocation of over 137,000 personnel across seven military installations.

Disclaimer: This is an entirely fictitious scenario built for demonstration purposes. Hurricane ELARA-26 doesn’t exist. Installation locations are based on real, publicly available geographic data (the U.S. Department of Defense [DoD] Military Installations, Ranges, and Training Areas [MIRTA] dataset), but all operational data, like personnel counts, housing capacity, assets, contact emails, and mission profiles, are completely fabricated. Nothing in this demo reflects actual military readiness, capability, or operational procedures.

Why automated disaster response requires geospatial and agentic coordination

When a natural disaster threatens critical infrastructure, the coordination challenge is immediate:

• Which facilities are in the impact zone?

• How many personnel need to move?

• Where can they go, and do those facilities have capacity?

• Who needs to be notified right now?

These questions don't wait. Neither should the answers.

Deploy the pipeline: prerequisites and setup

Follow the instructions here in the example repo to deploy a local Elastic cluster with Elastic Inference Service (EIS) via Cloud Connect.

How the Elasticsearch agentic disaster response pipeline works

The pipeline has seven layers that work together end to end:

1. Data ingestion: Global Disaster Alert and Coordination System (GDACS) disaster events sent to Elasticsearch

2. Ingest pipeline: GeoJSON is ingested and normalized to Elastic Common Schema (ECS).

3. Geospatial enrichment: The event's affected area polygon is matched against indexed military installation boundaries.

4. Alerting: A Kibana detection rule fires when a disaster intersects any installation.

5. Workflow automation: The alert triggers a Kibana workflow that starts an AI agent conversation.

6. AI reasoning: The agent reasons through affected facilities, their assets, and nearest supporting facilities to determine relocation of all assets and personnel.

7. Email notifications: The agent dispatches emails to all recipients for incoming and outgoing personnel and or assets.

Let's walk through each layer.

Step 1: Indexing military installations with geo boundaries

The foundation is the DoD MIRTA dataset from source.coop/seerai/hifld. This dataset provides a geo_shape of type Point for each installation; centroid coordinates rather than full boundary polygons.

Each installation document in the mitra-facilities index is enriched with operational profile data (all fictitious), beyond what MIRTA provides:

This rich index is what enables the AI agent to make intelligent allocation decisions; not just "here are nearby bases," but "here are bases with available housing capacity, compatible mission types, and the logistics to receive incoming assets."

Step 2: Ingesting and normalizing GDACS events

GDACS publishes real-time GeoJSON for earthquakes, tropical cyclones, floods, wildfires, volcanoes, and droughts. We ingest this feed into a data stream (logs-gdacs.events-*) using a custom ingest pipeline that normalizes the raw GeoJSON to ECS fields.

The GDACS ingest pipeline does several things worth noting:

Geometry extraction: The centroid is stored as a geo_point for map display, and the impact polygon is stored as a geo_shape in gdacs.affected_area, which is the field used for intersection queries later.

Severity normalization: Each disaster type has a different severity scale. A tropical cyclone is measured in km/h wind speed; an earthquake in Richter magnitude. The pipeline maps all of them to a normalized 0–100 score:

The normalized severity score then maps to a severity_level label (low, medium, high, critical) used for alert severity mapping in the detection rule.

ECS alignment: event.kind: alert, event.category: threat, timestamps mapped to event.start/event.end, and a stable fingerprint-based _id for deduplication.

Step 3: Geospatial enrichment: Finding affected facilities at index time

Elasticsearch's geo_match enrich policy matches the disaster polygon against every installation boundary at index time, with no query-time join required. Instead of querying at search time, we use an enrich processor in the ingest pipeline to match the disaster's impact polygon against every installation boundary as the document is indexed.

The enrich policy is a geo_match policy:

The processor runs at the end of the ingest pipeline:

INTERSECTS catches any installation whose boundary touches or overlaps the disaster polygon and even partial intersections. The result is that every GDACS event document is stored with an affected_facilities nested array that tells us exactly which installations are in the impact zone. No join query needed.

Step 4: Detection rule: Alerting on facility impact

A Kibana detection rule watches the logs-gdacs.events-* data stream and fires when a GDACS event has been enriched with at least one affected facility:

The rule runs on an hourly schedule (covering a now-1h to now window) and uses dynamic severity mapping; the gdacs.severity_level field computed by the ingest pipeline drives the alert severity automatically.

Alert severity also drives the risk score via field mapping:

When the rule fires, it passes the full alert context, including the enriched affected_facilities array with installation names, types, and locations, downstream to a Kibana workflow.

Step 5: Workflow automation: Bridging alert to agent

Kibana Workflows handle the handoff from detection to response. The natural disaster response workflow is triggered by the alert:

The entire alert payload (disaster type, severity, affected area, and the list of impacted installations) is forwarded to the AI agent as its initial context. The agent takes it from there.

Step 6: The AI agent: From data to coordinated action

The mitra.response agent takes the full alert payload and, in a single agentic loop, assesses scope, finds receiving facilities, allocates personnel and dispatches evacuation and intake notifications, all without human intervention.

The agent has two tools available:

• mitra.nearest_facilityqueries the mitra-facilities index using a geo_shape query, sorted by distance from a given coordinate, returning up to 50 nearby active installations with available capacity.

• mitra.send_email iterates over a JSON array of facility objects and dispatches formatted evacuation or receiving notifications.

The agent's instruction set defines a clear workflow:

1. Assess the situation. Parse the alert, identify affected facilities, and determine disaster scope.

2. Inventory what needs to move. Personnel counts, critical assets, housing requirements per facility.

3. Find destination facilities. Call mitra.nearest_facility for each affected installation, filtering out facilities still in the danger zone.

4. Make allocation decisions. Reason through single versus multi-facility solutions, branch compatibility, housing capacity, asset support.

5. Send coordination emails. Dispatch evacuation orders to source facilities and intake notifications to receiving facilities.

6. Produce a summary report. Produces a short summary of all affected facilities, total personnel, assets moved, destination facilities, and any concerns to the chat for review.

The agent's allocation logic follows real-world constraints: Don't exceed housing capacity, prefer same-branch relocations when possible, use joint bases for multi-branch overflow, and prioritize distance to minimize transit time.

The nearest facility tool

The underlying workflow query uses geo_shape with a circle filter and _geo_distance sorting:

Available capacity is computed at query time via a script field which calculates housing capacity minus current personnel count. The agent uses this to allocate personnel across destinations without exceeding limits.

Hurricane ELARA-26: agentic coordination of 137,000 personnel, end to end

Hurricane ELARA-26 is a Category 4 storm (213 km/h maximum winds) projected to make landfall in the Hampton Roads area of Virginia. When the GDACS event is ingested, the affected area polygon intersects seven major military installations in the region. The detection rule fires. The workflow kicks off an agent conversation.

Within a single agentic loop, the agent:

• Identified seven facilities in the impact zone, with a combined 137,372 personnel.

• Called mitra.nearest_facility to find receiving facilities outside the storm track.

• Distributed personnel across nine receiving facilities based on available housing capacity and distance.

• Generated and dispatched evacuation orders to all seven affected installations.

• Generated and dispatched intake notifications to all nine receiving facilities.

• Produced a full coordination summary, similar to below:

Facilities evacuated:

Facility

Personnel

Naval Station Norfolk

50,000

Joint Expeditionary Base Little Creek-Fort Story

18,000

Naval Air Station Oceana

15,355

Naval Air Station Oceana Dam Neck Annex

17,509

NG State Military Reservation Camp Pendleton

9,707

Joint Base Langley-Eustis

15,000

Naval Weapons Station Yorktown

11,801

Receiving facilities:

Facility

Distance

Incoming personnel

Fort Gregg-Adams

97 km

~40,000

Marine Corps Base Quantico

148 km

~30,000

Naval Support Facility Indian Head

151 km

~30,000

Joint Base Andrews

180 km

~30,000

Naval Air Station Patuxent River

141 km

~10,000

NG MTA Camp Butner

174 km

~5,000

NG Bethany Beach Training Site

209 km

~4,707

Rivanna Station

140 km

~7,500

Def Gen Supply Center

22 km

~6,000

Assets relocated include transport vehicles, helicopters, patrol boats, medical units, engineering vehicles, generators, water trailers, shelter kits, and communication systems.

Automated email notifications

Once the agent finalized its allocation plan, it called mitra.send_email and dispatched 16 emails in a single pass; that is, evacuation orders to all seven affected installations and intake notifications to all nine receiving facilities. Each message included destination facility, incoming personnel count, assets to move, and a coordination contact. What would have taken hours of phone trees completed automatically the moment the agent finished reasoning.

Extending agentic disaster response with RAG and policy grounding

This demo is purely from structured data, like capacity numbers, distances, and operational status. Elastic's semantic search and retrieval augmented generation (RAG) capabilities can make the agent significantly smarter, with two additions:

Historical response retrieval: Index past after-action reports, Federal Emergency Management Agency (FEMA) incident summaries, and disaster response records as vector embeddings. When a new event fires, the agent can semantically retrieve how similar events were handled, informing allocation decisions with institutional knowledge rather than capacity math alone.

Policy and doctrine grounding: Index DoD emergency management directives, installation continuity of operations plans, and commander guidance. The agent can retrieve and cite the actual policies governing a response, ensuring every decision is grounded in doctrine rather than inference.

Both follow the same Elastic-native approach:; An inference pipeline generates embeddings at index time, and a semantic search tool is exposed to the agent. The coordination pipeline stays the same. The agent just gets smarter.

Why Elasticsearch is the right platform for agentic public sector response

This isn’t a chatbot. It isn’t a dashboard. It's a responsive agentic workflow system, one that detected a threat, reasoned through a complex logistics problem, and coordinated the relocation of 137,000 people without a human in the loop. That kind of outcome is only possible because every capability it depends on lives in a single, unified platform.

Elasticsearch's geospatial support (geo_point, geo_shape, enrichment policies, and distance-based sorting) handles the spatial reasoning that makes intersection detection and facility lookup possible at scale. Semantic search and vector embeddings ground agents in truth, ensuring AI reasoning is based on what's actually in your data rather than hallucinated assumptions. Kibana's detection engine, Workflows, Agent Builder, and Agent Builder tools wire it all together into a pipeline that goes from raw event to coordinated action with no external glue code required.

No other platform brings this together the way Elastic does. The combination of real-time indexing, geospatial precision, semantic retrieval, and agentic orchestration, all in one stack, with enterprise-grade security and observability built in, is what separates Elastic from tools that do one of these things well but require you to stitch the rest together yourself.

Agentic geospatial response for emergency management, fire, law enforcement and public health

The same architecture applies wherever people, facilities, and real-time events intersect. The specific data changes. The pipeline doesn't.

Emergency management: FEMA and state offices of emergency management can map shelter locations, staging areas, and vulnerable populations against incoming National Weather Service (NWS) severe weather polygons, triggering automated resource pre-positioning before a storm makes landfall.

Fire and emergency medical services: Fire departments can overlay unit locations and response zones against wildfire perimeters or structure fire clusters, automatically routing mutual aid requests to the nearest available units with the right equipment.

Law enforcement: Agencies can correlate active incident locations with school zones, critical infrastructure, and officer positions, triggering geo-aware lockdown notifications or resource dispatch without waiting for manual triage.

Public school safety: School districts can monitor real-time threat feeds against campus boundaries. When a threat intersects a school's perimeter, an agent can immediately notify administration, initiate lockdown communications, and coordinate law enforcement response, all before a dispatcher picks up a phone.

Public health: Health departments can match disease surveillance data or environmental hazard zones against clinic locations, population density layers, and supply depot inventories to route resources where they're needed most.

Sector

Use case

Elastic capability

Emergency management

Match shelter locations against NWS severe weather polygons

geo_shape enrichment + Kibana Workflows

Fire and EMS

Overlay unit locations against wildfire perimeters

geospatial routing + nearest-facility query

Law enforcement

Correlate incidents with school zones and officer positions

geo-aware alert rules + agent dispatch

Public school safety

Monitor threat feeds against campus perimeters

detection rules + automated notification

Public health

Match hazard zones against clinic locations and supply depots

semantic search + geospatial enrichment

The data is different in every scenario. The underlying pattern of ingest, enrich at index time, detect intersection, trigger agentic response, and act is all the same. Elastic gives public sector organizations the platform to build it once and adapt it everywhere.

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.

How Kibana fetches data when loading a dashboard

When a Dashboard is opened, most of the panels (internally, we call these embeddables) kick off one or more Elasticsearch queries. But instead of the simple call-and-response of a synchronous (sync) search, we use the power of asynchronous (async) search (docs).

With async search, query results are kept available in Elasticsearch outside of any particular HTTP request. This is important because it

• makes data loading resilient to network turbulence

• powers our background search feature which allows users to work on other things in Kibana while they wait for a long-running dashboard or Discover session

After the initial query is submitted, Kibana monitors the search to detect when it is complete and retrieve the result set.

How traditional polling affects Kibana dashboard load times

In traditional polling, Kibana submits a query, closes the initial connection, then periodically checks Elasticsearch for completion.

We do give Elasticsearch a short amount of time after query submission to simply complete the search and return results. If the search completes that quickly, it amounts to a simple call-and-response. But for longer searches, the initial connection is closed and Kibana begins periodically checking the search for completion. This is called polling.

Performance drawbacks of traditional polling

Looking at the figure above, perhaps you can already see the performance drawback to this approach: the search is most likely to finish during one of Kibana’s sleep intervals, leading to lost time.

In the worst case scenario (when a search completes at the beginning of a sleep period) the entire duration of the polling interval will be wasted.

The impact of a backoff strategy

It’s standard practice when polling to apply a backoff strategy. This means that the longer the duration of the search, the less frequently we poll.

However, this also means that the potential lost time scales with the duration of the search.

How polling intervals create sawtooth latency patterns

Putting these factors together, our lost time becomes a stepwise sawtooth function.

Here, the peaks are worst-case scenarios and the troughs are best case scenarios. This illustrates that traditional polling costs us between nothing and the full duration of the polling interval, depending on the search duration (and network conditions).

Continuous polling: how Kibana eliminates wait time

The problem with traditional polling is a fundamental lack of coordination between Kibana and Elasticsearch. Ideally, Kibana knows immediately when results are available. So, what if we inverted the polling pattern to where nearly all of the time is spent checking Elasticsearch and no time is spent sleeping?

With this combination of long polling and no more sleep periods, results are delivered as soon as they are ready.

HTTP/1 degradation

The theory is solid. So why does this Kibana deployment look so degraded when we turn on continuous polling?

The key is that this deployment is running over HTTP/1. In HTTP/1, HTTP requests are mapped 1:1 to TCP connections. So several long-lived polling requests are hogging the browser’s finite connection pool, causing other requests to be queued.

In HTTP/2+ on the other hand, network requests can share TCP connections via multiplexing, so we don’t run into this problem.

So, on HTTP/2+ continuous polling is a virtue but on HTTP/1 it becomes a vice.

HTTP/1

HTTP/2+

TCP connections

One per HTTP request

Multiplexed (many requests share connections)

Continuous polling behaviour

Degrades performance (connection pool exhaustion)

Full benefit (results delivered immediately)

How Kibana detects HTTP protocol for optimal polling

HTTP/2 is the recommended protocol and it’s the Kibana default since 9.0, so it would be a shame not to ship this performance enhancement. On the other hand, the HTTP/1 experience is so degraded that it isn’t acceptable to risk it on any on-prem deployments who haven’t yet upgraded their protocol. The answer is clear: we need to detect which protocol is in use and apply the optimal polling strategy.

It is certainly possible for the Kibana server to know which protocol it is speaking. But, there’s a catch: the limiting factor is the browser’s connection pool. That means that what really matters is what the browser is speaking.

Because of proxies, these are not always the same.

If we based our optimization on the server protocol, we could get things wrong in one of two ways.

1. Apply continuous polling when we shouldn’t and degrade the experience.

2. Fail to apply continuous polling when we should and miss out on the optimization.

Luckily, modern browsers provide a way to detect the protocol of the last network hop of any completed request through the use of a PerformanceObserver. So, we watch for the protocol of the first query submission and optimize based on that.

Lab results: continuous polling vs. traditional polling in Kibana

To validate continuous polling, we created dashboards with query delays ranging from 1 to 23 seconds and measured load times with and without the optimization enabled. We then loaded the dashboards with and without continuous polling to measure the gains (we had a lot of fun with race-for-the-prize).

The pattern echoes our original sawtooth diagram. For some query durations, the gains are small while for others they amount to several seconds.

Conclusion

This optimization successfully replaces the latency inherent in traditional polling with a more efficient continuous polling strategy. The primary challenge was implementing this optimization conditionally to prevent performance degradation on HTTP/1 deployments. We solved it using the browser’s PerformanceObserver to reliably detect the protocol in use for the final network hop.

Laboratory testing validates the theory, showing continuous polling delivers results as soon as they are ready. On average, this leads to a meaningful improvement in user experience, making data load up to 25% faster.

This work is the latest step in our commitment to driving down time-to-insight for our users. By making Kibana a more transparent proxy to Elasticsearch data, we push the limits of performance within our sphere of influence. More to come!

(In 2025, Thomas Neirynk gave an excellent overview of the methods and motivation behind improving Kibana dashboard performance. This is an update on that initiative.)

Between Kibana 8.16 and 8.18, we tackled these issues head-on, introducing key improvements that shattered previous scalability barriers. Before these enhancements, Kibana Alerting could only support up to 3,200 rules per minute with at least 16 Kibana nodes before hitting significant performance bottlenecks. By Kibana 8.18, we’ve increased the scalability ceiling of rules per minute by 50x, supporting up to 160,000 lightweight alerting rules per minute. This was achieved by making Kibana efficiently scale beyond 16 Kibana nodes and increasing per-node throughput from 200 to up to 3,500 rules per minute. These enhancements make all alerting rules run faster, with fewer delays and more efficiently.

In this blog, we’ll explore the scaling challenges we overcame, the key innovations that made it possible, and how you can leverage them to run Kibana Alerting at scale efficiently.

How Kibana Alerting scales with Task Manager

Kibana Alerting allows users to define rules that trigger alerts based on real-time data. Behind the scenes, the Kibana Task Manager schedules and runs these rules.

The Task Manager is Kibana’s built-in job scheduler, designed to handle asynchronous background tasks separately from user interactions. Its key responsibilities include:

• Running one-time and recurring tasks such as alerting rules, connector actions, and reports.

• Dynamically distributing workloads as Kibana background nodes join or leave the cluster.

• Keeping the Kibana UI responsive by offloading tasks to dedicated background processes.

Each alerting rule translates into a recurring background task. Each background task is an Elasticsearch document, meaning it is stored, fetched and updated as an Elasticsearch document. As the number of alerting rules increases, so do the background tasks Kibana must manage. However, each Kibana node has a limit on how many tasks it can handle simultaneously. Once capacity is reached, additional tasks must wait, leading to delays and slower task run times.

The problem: Why scaling was limited

Before these improvements, Task Manager faced several scalability constraints, preventing it from scaling beyond 3,200 tasks per minute and 16 Kibana nodes. At this scale, we observed diminishing returns as contention and resource inefficiencies limited further scale. These numbers were based on internal performance testing using a basic Elasticsearch query alerting rule performing a no-op query. The diminishing returns observed included:

Task claiming contention

Task Manager uses a distributed polling approach to claim tasks within an Elasticsearch index. Kibana nodes periodically query for tasks and attempt to claim them using Elasticsearch’s optimistic concurrency control, which prevents conflicting document updates. If another node updates the task first, the original node drops it, reducing overall efficiency.

With too many Kibana nodes competing for tasks, document update conflicts increase drastically, limiting efficiency beyond 16 nodes and reducing system throughput.

Inefficient per-node throughput

Each Kibana node has a limit on the number of tasks that can run concurrently (default: 10 tasks at a time) to prevent memory and CPU overload. This safeguard often results in underutilized CPU and memory, requiring more nodes than necessary.

Additionally, the polling interval (default: 3000ms) defines how often Task Manager claims new tasks. A shorter interval reduces task delays but increases contention as nodes compete more for updates.

Resource inefficiencies

When running a high volume of alerting rules, Kibana nodes perform repetitive Elasticsearch queries, repeatedly loading the same objects and lists for each alerting rule run, consuming more CPU, memory, and Elasticsearch resources than necessary. Scaling up requires costly infrastructure expansions to support the increasing request loads.

Why it’s important

Breaking these barriers is crucial for Kibana’s continued evolution. Improved scalability unlocks:

• Cost optimization: Reducing infrastructure costs for large-scale operations.

• Faster recovery: Enhancing Kibana’s ability to recover from node or cluster failures.

• Future expansion: Enabling scalability for additional workloads, such as scheduled reports and event-driven automation.

Key innovations in Kibana Task Manager

To achieve a 50x scalability boost, we introduced several innovations:

Kibana discovery service: smarter scaling

Previously, Kibana nodes were unaware of each other’s presence, leading to inefficient task distribution. The new Kibana discovery service dynamically monitors active nodes and assigns task partitions accordingly, ensuring even load distribution and reducing contention.

Task partitioning: eliminating contention

To prevent nodes from competing for the same tasks, we introduced task partitioning. Tasks are now distributed across 256 partitions, ensuring only a subset of Kibana background nodes attempt to claim the same tasks at any given time. By default, each partition is assigned to a maximum of two Kibana nodes, while a single Kibana node can be responsible for multiple partitions.

Task costing: smarter resource allocation

Not all background tasks consume the same resources. We implemented a task costing system that assigns task weights based on CPU and memory usage. This allows Task Manager to dynamically adjust the number of tasks to claim, optimize resource allocation, and ensure efficient performance.

New task claiming algorithm

The old algorithm relied on update-by-query with forced index refresh to identify claimed tasks. This approach was inefficient and introduced unnecessary load on Elasticsearch. The new algorithm avoids this by searching for tasks without requiring an immediate refresh. Instead, it performs the following operations on the task manager index; a _search to find candidate tasks, followed by an _mget which returns documents that may have been updated more recently but are not yet reflected in the refreshed index state. By comparing document versions from _search and _mget results, it discards mismatches before proceeding with bulk updates. This approach increases efficiency in Elasticsearch and offers finer control to support task costing.

By factoring in the poll interval, task concurrency and the index refresh rate, we can calculate the upper limit of expected conflicts and adjust the _search page size accordingly. This helps ensure enough tasks are retrieved so the _mget doesn’t discard all the search results due to document version mismatches.

More frequent polling for tasks

By ensuring a fixed number of nodes compete for the same tasks with task partitioning and a new lightweight task claiming algorithm, Task Manager can now poll for tasks more frequently without additional stress on Elasticsearch. This reduces delays between a task completing and the next one starting, increasing overall system throughput.

Performance optimizations in Kibana Alerting

Before our optimizations using Elastic APM, we analyzed alerting rule performance and found that the alerting framework required at least 20 Elasticsearch queries to run any alerting rule. After the optimizations, we reduced this to just 3 queries - an 85% reduction, significantly improving run times and reducing CPU overhead.

Additionally, Elasticsearch previously relied on the resource-intensive pbkdf2 hashing algorithm for API key authentication, introducing excessive overhead at scale. We optimized authentication by switching to the more efficient SHA-256 algorithm, allowing us to eliminate the use of an internal Elasticsearch cache that was severely limited by the number of API keys used concurrently.

Impact: How users are benefiting

Early adoption has demonstrated:

• 50% faster rule run times, reducing overall system load.

• Increased task capacity, enabling more tasks to run on existing infrastructure.

• Fewer under-provisioned clusters, minimizing the need for scaling infrastructure to meet demand.

Drop in average task delay because of increased per-node throughput and making the cluster properly provisioned

Drop in rule run duration because of alerting framework optimizations

Drop in Elasticsearch requests because of alerting framework optimizations

Getting started: How to scale efficiently

Upgrading to Kibana 8.18 unlocks most of these benefits automatically. For additional optimization, consider adjusting the xpack.task_manager.capacity setting to maximize per-node throughput while ensuring p999 resource usage remains below 80% for memory, CPU, and event loop utilization and below 500ms for event loop delay.

By default, Kibana has a guardrail of 32,000 alerting rules per minute. If you plan to exceed this limit, you can modify the xpack.alerting.rules.maxScheduledPerMinute setting accordingly.

The new xpack.task_manager.capacity setting makes Kibana handle workload distributions more effectively, making the following settings unnecessary in most cases and should be removed from your kibana.yml settings:

• xpack.task_manager.max_workers

• xpack.task_manager.poll_interval

If you’re running Kibana on-prem and want to isolate background tasks into dedicated nodes, you can use the node.roles setting to separate UI-serving nodes from those handling background tasks. If you’re using Kibana on Elastic Cloud Hosted (ECH), scaling to 8GB or higher will automatically enable this isolation.

What’s next for Kibana Alerting?

We’re not stopping at 50x. Our roadmap aims for 100x+ scalability, further eliminating Elasticsearch bottlenecks.

Beyond scaling, we’re also focusing on improving system monitoring at scale. Upcoming integrations will provide system administrators with deeper insights into background task performance, making it easier to decide when and how to scale.

Additionally, with task costing, we plan to increase task concurrency for Elastic Cloud Hosted (ECH) customers when configured with more CPU and memory (e.g., Kibana clusters with 2GB, 4GB, or 8GB+ of memory).

Stay tuned for even more advancements as we continue to push the limits of Kibana scalability!

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.

In this article we'll take a look at the new code generation feature in the Kibana Dev Console, and how it can significantly reduce your development effort by generating ready to use code for you.

This feature is available in our Serverless platform and in Elastic Cloud and self-hosted releases 8.16 and up.

The Kibana Dev Console

This section provides a quick introduction to the Kibana Dev Console, in case you have never used it before. Skip to the next section if you are already familiar with it.

While you are in any part of the Search section in Kibana, you will notice a "Console" link at the bottom of your browser's page:

When you click this link, the Console expands to cover the page. Click it again to collapse it.

In the left-side panel of the Dev Console, you can enter Elasticsearch requests, with the help of an interactive editor that provides auto-completion and checks your syntax. Some example requests are already pre-populated so that you have something to start experimenting with.

When the cursor is on a request, a "play" button appears to its right. You can click this button to send the request to your Elasticsearch server.

After you execute a request, the response from the server appears in the panel on the right.

Code Export feature in Kibana Dev Console

The Dev Console makes it easy to prototype your requests or queries until you get exactly what you want. But what happens next? If you need to convert the request to code so that you can incorporate it into your application, then you can save time using the new code export feature.

Next to the Play button you will find the three dot or "kebab" button, which opens a menu of options. The first option provides access to the code export feature. If you've never used this feature before, it will appear with a "Copy as curl" label.

If you select this option, your clipboard will be loaded with a curl command that is equivalent to the selected request.

Now, things get more interesting when you click the "Change" link, which allows you to switch to a different target language. In this initial release, the code export adds support for Python and JavaScript. More languages are expected to be added in future releases.

You can now select your desired language and click "Copy code" to put the exported code in your clipboard. You can also change the default language that is offered in the menu.

The exported code is a complete script in the selected language, using the official Elasticsearch client for that language. Here is an example of how the PUT /my-index request shown above looks when exported to the Python language:

To use the exported code follow these steps:

• Paste the code from the clipboard to a new file with the correct extension (.py for Python, or .js for JavaScript).

• In your terminal, add an environment variable called ELASTIC_API_KEY with a valid API Key for your Elasticsearch cluster. You can create an API key right in Kibana if you don't have one yet.

• Execute the script with the python or node commands depending on your language, making sure the official Elasticsearch client is installed.

Now you are ready to adapt the exported code as needed to integrate it into your application!

Conclusion

In this article you have learned about the new Code Export feature in the Kibana Dev Console. We hope this feature will streamline your development process with Elasticsearch!