Kibana breaking changes

Details
The following Workflows API routes previously accepted callers holding only the workflowsManagement:readExecution privilege (the Read Workflow Execution sub-feature privilege, workflow_execution_read). Execution documents include a YAML snapshot of the workflow definition, so those callers could retrieve a workflow definition without holding the workflowsManagement:read privilege (Read, workflow_read). Reading execution data now requires both privileges. This applies to every execution read route, including the list and search routes:

• GET /api/workflows/executions/{executionId}
• GET /api/workflows/executions/{executionId}/step/{stepExecutionId}
• GET /api/workflows/executions/{executionId}/logs
• GET /api/workflows/executions/{executionId}/children
• GET /api/workflows/workflow/{workflowId}/executions
• GET /api/workflows/workflow/{workflowId}/executions/steps
• GET /api/workflows/workflow/executions

Impact
API callers or custom Kibana roles that grant workflow_execution_read without workflow_read receive HTTP 403 on the routes listed above.

Action
In any role that customizes Workflows sub-feature privileges, add Read (workflow_read) under Analytics → Workflows → Workflows Actions alongside Read Workflow Execution (workflow_execution_read). Roles that grant All or Read on Analytics → Workflows already include both privileges and need no change.

View #285645.

Details
Kibana now ships nodemailer 9, which validates the proxy server's TLS certificate when the email connector sends mail through an HTTPS proxy. Earlier versions skipped that check, so a proxy with a self-signed, expired, or hostname-mismatched certificate now causes sending to fail. Hosted and cloud SMTP with public certificate authorities is unaffected.

Impact
Self-managed deployments that route email through an HTTPS proxy with a certificate that isn't trusted by default can no longer send email until TLS verification is updated.

Action
Trust the proxy certificate, or set xpack.actions.ssl.proxyVerificationMode: none to restore the previous behavior. Note that certificate behaves the same as full on the proxy connection: a custom CA or relaxed hostname check does not apply there.

View #283150.

Details
Fleet package policy validation for additional_datastreams_permissions previously used a regex that didn't enforce its documented <type>-<suffix> datastream prefix grammar (for example logs-nginx-*). A value only needed to start with logs, contain metrics, traces, or synthetics, or end with profiles-... to pass.

Impact
Package policy requests that set additional_datastreams_permissions to a value that doesn't match the <type>-<suffix> grammar — such as a dashless value or one starting with a wildcard, for example logs* — are now rejected.

Action
Update any additional_datastreams_permissions values to the <type>-<suffix> form, for example logs-nginx-*.

View #282404.

Details
Kibana now uses the browser's Accept-Language preferences to choose the interface language. This applies on all deployment types when a user hasn't set a language in their profile and has no KBN_LOCALE cookie. If the browser's preferred language is German, French, Japanese, or Simplified Chinese and is listed in i18n.locales, Kibana displays in that language instead of English. All bundled locales are listed by default. Kibana then saves the resolved language in the KBN_LOCALE cookie, so it stays in place on later visits. Setting i18n.defaultLocale: en doesn't stop this, because the browser preference is only skipped when i18n.defaultLocale is set to a value other than en. Refer to Resolution priority.

Impact
After upgrading, some users may see Kibana in a language other than English without changing anything themselves. This is most likely in organizations that manage browser language settings centrally. Internal runbooks, screenshots, and training based on the English UI may no longer match what users see.

Action
Users can change their language at any time from the user menu or their profile page.

To keep English as the default for everyone while still letting users choose another language, upgrade to 9.5.6 or later and set the following settings in kibana.yml:

i18n.detectBrowserLocale: false
i18n.allowLocaleCookie: false

i18n.detectBrowserLocale: false stops Kibana from reading the browser's language. i18n.allowLocaleCookie: false stops existing KBN_LOCALE cookies, which might already hold the detected language, from overriding the default. Users who already saved a language in their profile keep it.

If you can't upgrade to the latest 9.5.x patch yet, set i18n.locales: ["en"] to restore the previous English-only behavior. This also turns off per-user language selection.

View #275996 and #295756.

Details
The duration format used in visualization configuration now uses short-hand unit values aligned with ES|QL conventions for its from and to options. This affects the api/visualizations and api/dashboards APIs for both by-value and by-reference panels.

Impact
API requests that configure duration formats with previous verbose unit names, such as milliseconds, minutes, humanize, or asMilliseconds, are rejected.

Action
Update the duration from and to values in visualization and dashboard panel API payloads to the short-hand units, such as ms, min, auto, or auto-approximate.

View #274792.

Details
The response envelope for the Dashboards API search endpoint changes from { dashboards, page, total } to { data, meta }. The pagination fields (page, per_page, and total) move under meta. The endpoint also enforces a maximum per_page of 1,000.

Impact
Clients that read dashboards, page, or total at the top level no longer receive those fields. Requests with per_page above 1,000 are rejected.

Action
Update Dashboards API search clients to read results from data and pagination from meta, and keep per_page at or below 1,000.

View #268951.

Details
POST /api/fleet/managed_integrations (previously POST /api/fleet/agentless_policies) now returns a dedicated ManagedIntegration response model instead of the internal PackagePolicy shape. The format query parameter is removed. The request body no longer accepts description, var_group_selections, additional_datastreams_permissions, or condition.

Impact
External API clients that read PackagePolicy fields such as policy_ids, revision, supports_agentless, secret_references, output_id, fleet_server_host_id, or enabled from the response receive a different payload. Requests that include removed body fields or the format query parameter fail validation.

Action
Update integrations to consume the ManagedIntegration fields (id, name, namespace, package, inputs, vars, global_data_tags, cloud_connector, and timestamps). Remove the format query parameter and dropped request body fields from create calls.

View #272894.

Details
GET /api/status now requires the Elasticsearch cluster:monitor privilege to return the full payload, including host info, build details, core and plugin status, and metrics. Authenticated callers without monitor, and callers when the privilege check fails, receive { "status": { "overall": { "level": "<level>" } } }. Unauthenticated Kubernetes liveness and readiness probes are unchanged. The /status UI shows an informational prompt for users without monitor when the bypass is turned off.

Impact
Monitoring scripts or automation that call /api/status with credentials lacking cluster:monitor receive a redacted response instead of build, host, and plugin details. The /status page shows limited information for those users.

Action
Grant cluster:monitor to monitoring users and roles that need the full status payload. While updating roles, set status.statusPageBypassMonitorPrivilege: true to preserve the previous authenticated behavior.

View #268942.

Details
Kibana 9.5 removes HTML string output from field formatters, including the 'html' content type and related conversion utilities. Field formatters now return plain text or React elements. This change does not affect formatted values in the Kibana UI.

Impact
External plugins that request 'html' output or consume HTML strings from field formatters must be updated for Kibana 9.5.

Action
When updating your external plugin, replace HTML formatting calls with convertToText() or convertToReact(). For @kbn/discover-utils, use formatFieldValueText or formatFieldValueReact.

View #267517.

Details
Creating, updating, upgrading, or copying managed integrations (formerly agentless) through the Fleet package policy (/api/fleet/package_policies) and agent policy (/api/fleet/agent_policies) APIs is no longer supported. These operations are served exclusively by the Managed integrations API (/api/fleet/managed_integrations). This affects Elastic Cloud Hosted deployments and Elastic Cloud Serverless projects where managed integrations are enabled. Self-managed deployments are not affected.

Impact
Requests that create, update, upgrade, or copy managed integrations through the package policy or agent policy APIs now fail with a 400 error. Existing managed integrations are not affected: they keep running and are upgraded and reconciled automatically, with no action required. Only clients that call the package policy or agent policy APIs directly for these write operations need to change.

Action
Use the Managed integrations API (/api/fleet/managed_integrations) to create, update, upgrade, or copy managed integrations, and update any automation that relied on the package policy or agent policy APIs for these operations.

View #280959.

Details
The index and component template forms in Index Management previously saved the _source field mode (stored and synthetic) in the mappings._source.mode setting. This path is deprecated and has no effect in Elasticsearch. The form now uses the correct settings.index.mapping.source.mode setting. Other _source options (enabled, includes, and excludes) remain in mappings.

Impact
When you edit a template in the UI, any existing mappings._source.mode setting is automatically moved to the index settings and removed from mappings.

Action
The migration happens automatically when you edit a template in the Index Management UI. If you manage templates outside the UI (via API or configuration files), update them to use settings.index.mapping.source.mode instead of mappings._source.mode.

View #255122.

Details
The Agent Builder ES|QL tool API now uses simplified parameter types aligned with ES|QL's actual capabilities instead of Elasticsearch field types. The supported configuration.params[*].type values are now: string, integer, float, boolean, and date. Previously accepted types (text, keyword, long, double, object, nested) are no longer valid for new API requests. Additionally, defaultValue is now restricted to string | number | boolean and requires optional: true to be set.

Impact
API calls to POST /api/agent_builder/tools or PUT /api/agent_builder/tools/{id} that use legacy parameter types will be rejected with a 400 error. Existing tools stored with legacy types are automatically migrated on read: text/keyword/object/nested become string, long becomes integer, and double becomes float. Legacy object/nested default values are JSON-stringified.

Action
Update any integrations that create or update ES|QL tools via the API to use the new type values:

• Use string instead of text, keyword, object, or nested
• Use integer instead of long
• Use float instead of double
• Ensure defaultValue is only provided when optional: true

View #249855.

Details
The index and component template forms in Index Management previously saved the _source field mode (stored and synthetic) in the mappings._source.mode setting. This path is deprecated and has no effect in Elasticsearch. The form now uses the correct settings.index.mapping.source.mode setting. When you edit a template in the UI, any existing mappings._source.mode setting is automatically moved to the index settings and removed from mappings. Other _source options (enabled, includes, and excludes) remain in mappings.

View #255122.

Details
Roles with explicit read access to advanced settings but all access to SavedObjectManagement can no longer update settings using the internal advanced settings API. This update enforces explicit privileges instead of relying on saved object security checks. View #230067.

Details
Fields and functions variables are now described with ?? in ES|QL queries. For value variables, you can continue to use ?.

View #213916.

Details
In 9.1.0, report generation requests are authenticated by API keys instead of session cookies. There are several key differences between the authentication methods. API keys capture your role privileges, whereas session cookie are based on your user credentials. API keys are also longer-lived, compared to session cookies, which have a shorter lifespan.

If you have a cross-cluster search environment and want to generate reports from remote clusters, you must have the appropriate cluster and index privileges on the remote cluster and local cluster. For example, if requests are authenticated with an API key, the API key requires certain privileges on the local cluster that contains the local index, in addition to the remote. For more information and examples, refer to Configure roles and users for remote clusters.

View #216558.

Access to internal Kibana HTTP APIs is restricted from version 9.0.0. This is to ensure that HTTP API integrations with Kibana avoid unexpected breaking changes.

Impact
Any HTTP API calls to internal Kibana endpoints will fail with a 400 status code starting from version 9.0.0.

Action
Do not integrate with internal HTTP APIs. They may change or be removed without notice, and lead to unexpected behaviors. If you would like some capability to be exposed over an HTTP API, create an issue. We would love to discuss your use case.

View #193792.

• POST /api/alerts/alert/{id?} has been replaced by POST /api/alerting/rule/{id?}
• GET /api/alerts/alert/{{id}} has been replaced by GET /api/alerting/rule/{{id}}
• PUT /api/alerts/alert/{{id}} has been replaced by PUT /api/alerting/rule/rule/{{id}}
• DELETE: /api/alerts/alert/{{id}} has been replaced by DELETE /api/alerting/rule/{{id}}
• POST /api/alerts/alert/{{id}}/_disable has been replaced by POST /api/alerting/rule/{{id}}/_disable
• POST /api/alerts/alert/{{id}}/_enable has been replaced by POST /api/alerting/rule/{{id}}/_enable
• GET /api/alerts/_find has been replaced by GET /api/alerting/rules/_find
• GET /api/alerts/_health has been replaced by GET /api/alerting/rule/_health
• GET /api/alerts/list_alert_types has been replaced by GET /api/alerting/rule_types
• POST /api/alerts/alert/{{alert_id}}/alert_instance/{{alert_instance_id}}/_mute has been replaced by POST /api/alerting/rule/{{rule_id}}/alert/{{alert_id}}/_mute
• POST /api/alerts/alert/{{alert_id}}/alert_instance/{{alert_instance_id}}/_unmute has been replaced by POST /api/alerting/rule/{{rule_id}}/alert/{{alert_id}}/_unmute
• POST /api/alerts/alert/{{id}}/_mute_all has been replaced by POST /api/alerting/rule/{{id}}/_mute_all
• POST /api/alerts/alert/{{id}}/_unmute_all has been replaced by POST /api/alerting/rule/{{id}}/_unmute_all
• POST /api/alerts/alert/{{id}}/_update_api_key has been replaced by POST /api/alerting/rule/{{id}}/_update_api_key
• GET /api/alerts/{{id}}/_instance_summary has been deprecated without replacement. Will be removed in v9.0.0
• GET /api/alerts/{{id}}/state has been deprecated without replacement. Will be removed in v9.0.0

Impact
Deprecated endpoints will fail with a 404 status code starting from version 9.0.0.

Action
Remove references to GET /api/alerts/{{id}}/_instance_summary endpoint. Remove references to GET /api/alerts/{{id}}/state endpoint. Replace references to endpoints listed as deprecated by it’s replacement. See Details section. The updated APIs can be found in https://www.elastic.co/docs/api/doc/kibana/group/endpoint-alerting.

Details

The following deprecated configuration settings were removed:

• xpack.actions.customHostSettings.ssl.rejectUnauthorized
• xpack.actions.whitelistedHosts
• xpack.actions.rejectUnauthorized
• xpack.actions.proxyRejectUnauthorizedCertificates
• xpack.alerts.healthCheck
• xpack.alerts.invalidateApiKeysTask.interval
• xpack.alerts.invalidateApiKeysTask.removalDelay
• xpack.alerting.defaultRuleTaskTimeout

View #198435.

Details

The following Cases APIs were removed:

• Get case status
• Get user actions
• Get all comments

• GET /api/cases/status is deleted with no replacement
• GET /api/cases/{{case_id}}/comments is replaced by GET /api/cases/{{case_id}}/comments/_find, released in v7.13
• GET /api/cases/<case_id>/user_actions is replaced by GET /api/cases/<case_id>/user_actions/_find, released in v8.7
• includeComments parameter in GET /api/cases/{{case_id}} is deprecated. Use GET /api/cases/{{case_id}}/comments/_find instead, released in v7.13

Impact
Using these endpoints will fail with a 404 status code starting from version 9.0.0.

Action
Remove references to the GET /api/cases/status endpoint. Replace references to other endpoints with the replacements listed in the breaking change details.

View #208208, #208086, and #207926.

Details

Ephemeral tasks are now removed. The following settings will no longer have any effect and are now deprecated:

• xpack.task_manager.ephemeral_tasks.enabled
• xpack.task_manager.ephemeral_tasks.request_capacity
• xpack.alerting.maxEphemeralActionsPerAlert

No action is required on the user's end.

View #201313 and #197421.

Details
Starting from version 9.0.0, search sessions are disabled by default. To view, manage, and restore search sessions, the feature needs to be explicitly re-enabled.

Impact
Search sessions will be disabled unless they are explicitly enabled in config.yml.

Action
If you would like to continue using, managing, and restoring search sessions in 9.0, you’ll need to re-enable the feature in your kibana.yml configuration file. If not, no action is necessary.

To re-enable search sessions, add the following in your config.yml:

data.search.sessions.enabled: true

View #203927.

Details

Saved query privileges have been reworked to rely solely on a single global savedQueryManagement privilege, and eliminate app-specific overrides (e.g. implicit access with all privilege for Discover, Dashboard, Maps, and Visualize apps). This change simplifies the security model and ensures consistency in the saved query management UI across Kibana, but results in different handling of saved query privileges for new user roles, and minor breaking changes to the existing management UX.

Impact

The savedQueryManagement feature privilege now globally controls access to saved query management for all new user roles. Regardless of privileges for Discover, Dashboard, Maps, or Visualize, new user roles follow this behaviour:

• If savedQueryManagement is none, the user cannot see or access the saved query management UI or APIs.
• If savedQueryManagement is read, the user can load queries from the UI and access read APIs, but cannot save queries from the UI or make changes to queries through APIs.
• If savedQueryManagement is all, the user can both load and save queries from the UI and through APIs.

Action

Existing user roles that were previously implicitly granted access to saved queries through the dashboard, discover, visualize, or maps feature privileges will retain that access to prevent breaking changes. While no action is required for existing roles, it’s still advisable to audit relevant roles and re-save them to migrate to the latest privileges model. For new roles, ensure that the savedQueryManagement privilege is set as needed.

View #202863.

The discover:searchFieldsFromSource advanced setting has been removed.

Details

Users can no longer configure Discover to load fields from _source. This is an internal optimization and should have little impact on users. View #202679.

Details

It's no longer possible to use the legacy documents table in Discover. To that effect, the doc_table:legacy and truncate:maxHeight deprecated advanced settings have been removed. View #201254.

Impact

This is primarily a UX change and should have little impact on Discover users.

Details

The ability to create new scripted fields has been removed from the Data Views management page in 9.0. Existing scripted fields can still be edited or deleted, and the creation UI can be accessed by navigating directly to /app/management/kibana/dataViews/dataView/{dataViewId}/create-field, but we recommend migrating to runtime fields or ES|QL queries instead to prepare for removal.

Impact

It will no longer be possible to create new scripted fields directly from the Data Views management page.

Action

Migrate to runtime fields or ES|QL instead of creating new scripted fields. Existing scripted fields can still be edited or deleted.

Details

The visualization:colorMapping advanced setting for TSVB and Visualize charts has been removed. You can switch to Lens charts, which offer a more advanced, per-chart color mapping feature with enhanced configuration options. View #162389.

Details

The Behavioral Analytics feature is removed from the Kibana interface in 9.0 and its associated APIs are deprecated.

View #212031.

Details

View #202278.

Details

Logs Stream and the logs settings page in Observability are removed. Use the Discover application, which now offers a contextual experience for logs, to explore your logs. The logs stream panel in dashboards is removed, use Discover sessions instead.

View #203996.

Details

Logs explorer has been removed. Instead, you can use Discover, that was improved to provide an optimal logs exploration experience. View #203685.

Details

• GET/DELETE/POST enrollment-api-keys: removed in favor of GET/DELETE/POST enrollment_api_keys
• Removed list property from GET enrollment_api_keys response in favor of items
• GET/POST /settings: fleet_server_hosts was removed from the response and body

View #198799.

Details

Removed API endpoints:

• POST /service-tokens in favor of POST /service_tokens
• GET /agent-status in favor GET /agent_status
• PUT /agents/:agentid/reassign in favor of POST /agents/:agentid/reassign

Removed deprecated parameters or responses:

• Removed total from GET /agent_status response
• Removed list from GET /agents response

View #198313.

Details

• Removed GET/POST/DELETE /epm/packages/:pkgkey APIs in favor of GET/POST/DELETE /epm/packages/:pkgName/:pkgVersion
• Removed experimental query parameter in GET /epm/packages and GET /epm/categories
• Removed response in response in * /epm/packages* and GET /epm/categories
• Removed savedObject in /epm/packages response in favor of installationInfo

View #198434.

Details

Removed deprecated property topics from output APIs in response and requests ((GET|POST|PUT) /api/fleet/outputs) in favor of the topic property. View #199226.

Details

In addition to the new pagination limit size of 100, retrieving agent policies without agent count is now the new default behavior, and a new query parameter withAgentCount was added to retrieve the agent count.

View #196887.

In 8.x, the default access control model was based on a built-in role called reporting_user, which granted access to reporting features. Since 7.13, the preferred model for controlling access to reporting features has been Kibana feature privileges, enabled by setting xpack.reporting.roles.enabled: false in kibana.yml.

In 9.0.0, the xpack.reporting.roles.* settings will be ignored.

Impact
The built-in reporting_user role is no longer deprecated and provides access to reporting features using Kibana feature privileges. This means that users that do not have privileges to use reporting will not see reporting features in the Kibana UI.

Action
Use Kibana feature privileges to control access to reporting features.

• The reporting_user role is still supported, but gives full access to all reporting features. We recommend creating custom roles with minimal privileges in Stack Management > Roles.
• The xpack.reporting.roles.allow setting is no longer supported. If you have a xpack.reporting.roles.allow value in your kibana.yml, you should remove this setting and assign privileges to reporting features using Kibana feature privileges.

View #200834.

Details

The functionality that allowed to download a CSV export from a dashboard's saved search panel without creating a report has been removed. To export CSV data from a dashboard panel, you may use the action menu of a saved search panel in a dashboard to generate a CSV report, and download the report from a toast popup when the report has finished generating.

View #199033.

Upgrade Assistant public APIs for reindexing and batch reindexing have been made internal. You should instead use Elasticsearch’s native reindexing APIs for programmatic reindexing.

View #214051.

All v1 Kibana security HTTP endpoints have been removed.

GET /api/security/v1/logout has been replaced by GET /api/security/logout GET /api/security/v1/oidc/implicit has been replaced by GET /api/security/oidc/implicit GET /api/security/v1/oidc has been replaced by GET /api/security/oidc/callback POST /api/security/v1/oidc has been replaced by POST /api/security/oidc/initiate_login POST /api/security/v1/saml has been replaced by POST /api/security/saml/callback GET /api/security/v1/me has been removed with no replacement.

Impact
Any HTTP API calls to the v1 Kibana security endpoints will fail with a 404 status code starting from version 9.0.0. Third party OIDC and SAML identity providers configured with v1 endpoints will no longer work.

Action
Update any OIDC and SAML identity providers to reference the corresponding replacement endpoint listed above. Remove references to the /api/security/v1/me endpoint from any automations, applications, tooling, and scripts.

View #199656.

Details

Legacy OpenSSL algorithms have been disabled by default. Further information on which algorithms can be found at https://docs.openssl.org/3.0/man7/OSSL_PROVIDER-legacy. These can be re-enabled by adding --openssl-legacy-provider to $KBN_PATH_CONF/node.options. View #213123.

Details

View #203856.