How to create a Kibana data view

A Kibana data view is what makes Elasticsearch indices, aliases, and data streams usable in Discover, Lens, dashboards, and rules. Creating the right view keeps searches scoped to the intended data source and prevents empty results caused by selecting the wrong pattern or time field.

A data view is a Kibana saved object that stores the pattern Kibana should query plus field metadata such as the default time field. The title can match one or more indices, aliases, or data streams with wildcards, while timeFieldName decides how the global time picker filters documents and how time-based histograms are built.

Creating or saving data views requires the Data View Management Kibana privilege and the view_index_metadata Elasticsearch privilege on the matching targets. The examples below use a direct local HTTP endpoint for clarity; when Kibana security or TLS is enabled, add the appropriate authentication headers or --user plus --cacert, insert any configured Kibana base path before /api/data_views, and add /s/<space_id> for a non-default space.

1. Confirm the pattern resolves to the intended indices, aliases, or data streams.

   $ curl --silent --show-error --fail "http://localhost:9200/_resolve/index/logs-app-*-default?expand_wildcards=all" | jq '{data_streams: [.data_streams[] | {name: .name, backing_indices: .backing_indices}]}'
   {
     "data_streams": [
       {
         "name": "logs-app-prod-default",
         "backing_indices": [
           ".ds-logs-app-prod-default-2026.04.02-000001"
         ]
       },
       {
         "name": "logs-app-staging-default",
         "backing_indices": [
           ".ds-logs-app-staging-default-2026.04.02-000001"
         ]
       }
     ]
   }

   Current Elastic stacks often route logs-* patterns through built-in data stream templates, so _resolve/index may return data streams and backing indices instead of standalone daily indices. A Kibana data view can target indices, aliases, or data streams the same way.

   Use the exact target pattern that the producer writes, such as metrics-*, traces-*, a concrete alias, or a custom application prefix.

2. Confirm the intended time field is mapped as a date or date_nanos field.

   $ curl --silent --show-error --fail "http://localhost:9200/logs-app-*-default/_field_caps?fields=@timestamp" | jq '{field: .fields["@timestamp"]}'
   {
     "field": {
       "date": {
         "type": "date",
         "metadata_field": false,
         "searchable": true,
         "aggregatable": true
       }
     }
   }

   If the documents use a different event time field, substitute that field name here and in timeFieldName in the creation request.

3. Create the data view with the Kibana API.

   $ curl --silent --show-error --fail \
     --header "kbn-xsrf: true" \
     --header "Content-Type: application/json" \
     --request POST "http://localhost:5601/api/data_views/data_view" \
     --data '{
       "data_view": {
         "title": "logs-app-*-default",
         "name": "Application logs",
         "timeFieldName": "@timestamp"
       }
     }' | jq '{data_view: {id: .data_view.id, name: .data_view.name, title: .data_view.title, timeFieldName: .data_view.timeFieldName, allowNoIndex: .data_view.allowNoIndex, namespaces: .data_view.namespaces}}'
   {
     "data_view": {
       "id": "c816e289-03e1-4bd9-804c-3969fc1e618d",
       "name": "Application logs",
       "title": "logs-app-*-default",
       "timeFieldName": "@timestamp",
       "allowNoIndex": false,
       "namespaces": [
         "default"
       ]
     }
   }

   Add /s/<space_id> before /api/data_views/data_view when the data view belongs to a non-default Kibana space.

   The kbn-xsrf header is required for non-GET Kibana API requests.

   Set allowNoIndex to true only when the pattern is expected to exist later and the data view must be saved before data arrives.

   If Kibana security or TLS is enabled, replace the plain HTTP endpoint with the correct https:// URL and add authentication with an API key or --user plus the appropriate --cacert file.

4. Fetch the data view by id and confirm Kibana saved the expected pattern and time field.

   $ curl --silent --show-error --fail "http://localhost:5601/api/data_views/data_view/c816e289-03e1-4bd9-804c-3969fc1e618d" | jq '{data_view: {id: .data_view.id, name: .data_view.name, title: .data_view.title, timeFieldName: .data_view.timeFieldName, namespaces: .data_view.namespaces}}'
   {
     "data_view": {
       "id": "c816e289-03e1-4bd9-804c-3969fc1e618d",
       "name": "Application logs",
       "title": "logs-app-*-default",
       "timeFieldName": "@timestamp",
       "namespaces": [
         "default"
       ]
     }
   }

   Matching title and timeFieldName confirm that Kibana saved the data view that Discover and other apps will reference.

5. Open Stack Management → Data Views and confirm the new entry is listed.

   A working data view also appears in Discover, Lens, and other Kibana pages that ask for a data source.

   If the page shows a read-only indicator or the save button is missing, the account does not have the required Data View Management privilege, the matching Elasticsearch privileges, or both.