How to delete a Kibana data view

Deleting an unused Kibana data view removes stale source choices from Discover, Lens, dashboards, and rule editors so operators do not accidentally query retired indices, aliases, or data streams.

A Kibana data view is a saved object that stores the source pattern plus metadata such as the default time field, runtime fields, and field formatting. Deleting the data view removes that saved object from Kibana, but it does not delete the underlying Elasticsearch indices, aliases, data streams, or documents.

Removing a data view is permanent and can break saved searches, dashboards, visualizations, and rules that still reference the deleted id. Current data-view management also requires the Data View Management Kibana privilege plus the view_index_metadata Elasticsearch privilege on the matching targets; self-managed deployments behind TLS or a reverse proxy may also need a CA certificate, a base-path prefix before /api, and either basic authentication or an API key header.

Steps to delete a Kibana data view:

List the current data views and identify the target id.

$ curl --silent --show-error --fail "http://localhost:5601/api/data_views" | jq '{data_view: [.data_view[] | {id: .id, name: .name, title: .title, namespaces: .namespaces}]}'
{
  "data_view": [
    {
      "id": "911b79d2-db84-4a7f-9dfe-15c8079e3a1a",
      "name": "Application logs",
      "title": "logs-app-*",
      "namespaces": [
        "default"
      ]
    },
    {
      "id": "c5076b9d-d432-4356-b2e8-024eba360b1d",
      "name": "Application metrics",
      "title": "metrics-app-*",
      "namespaces": [
        "default"
      ]
    }
  ]
}

Non-GET data-view API calls need the kbn-xsrf header, but a simple listing request does not. For a non-default space, use /s/<space_id>/api/data_views; if Kibana is published under a base path such as /kibana, insert that prefix before /api.

Export or replace anything that still depends on the target data view before removal.

Related: Export Kibana saved objects, Create a Kibana data view.

If the Data Views management page marks the entry as managed or does not offer a delete action, Kibana is either treating it as an Elastic-managed data view or the current account is missing the required Data View Management privilege.
Delete the data view with its id.
```
$ curl --silent --show-error --fail --output /dev/null --write-out "%{http_code}\n" --header "kbn-xsrf: true" --request DELETE "http://localhost:5601/api/data_views/data_view/911b79d2-db84-4a7f-9dfe-15c8079e3a1a"
200
```
Current self-managed Kibana 9.3.x builds return 200 with an empty body when the delete succeeds. Adjust automation accordingly if it currently waits for 204.

Deletion cannot be undone and breaks saved objects that still reference the deleted data view id.

Verify the deleted entry no longer appears in the data-view list.

$ curl --silent --show-error --fail "http://localhost:5601/api/data_views" | jq '{data_view: [.data_view[] | {id: .id, name: .name, title: .title, namespaces: .namespaces}]}'
{
  "data_view": [
    {
      "id": "c5076b9d-d432-4356-b2e8-024eba360b1d",
      "name": "Application metrics",
      "title": "metrics-app-*",
      "namespaces": [
        "default"
      ]
    }
  ]
}

The missing Application logs entry confirms Kibana removed that data view while leaving the other saved data source intact.

Open Stack Management → Data Views and confirm the removed entry is gone.

Current Kibana builds also expose the same page from the navigation menu or from the global search field.

If a dashboard, Lens visualization, or Discover session now fails to load, restore the saved objects from export or recreate the data view the missing content expected.