Why your Kibana dashboard time picker stopped working after changing the data view

The broken time picker after a data view change

You open a Kibana dashboard that worked yesterday, and the time picker shows no data. The index pattern still exists, the indices still contain logs, but relative ranges like 'Last 15 minutes' return nothing. The likely cause is the data view's time field.

In Kibana 8.x, Stack Management calls them data views; older versions and some saved-object types still say index pattern. A data view maps one or more Elasticsearch indices or data streams to Kibana and designates a single time field. That field powers the Discover time picker, relative-time queries, and the time filters stored inside saved searches and dashboards.

If you change that field—or recreate the data view with a new internal ID—saved objects that reference it can stop loading. This post explains how to pick the right time field, verify it before you build, and check whether existing dashboards still point to the right data view.

What the time field actually controls

The time field is not just a display preference. Kibana uses it to:

• Populate the Discover time picker with the field's values.
• Translate relative ranges such as 'now-15m' into queries against that field.
• Apply time filters when you open a saved search or dashboard.

If you point a data view at a field that is not a date type—such as a numeric ID or a keyword—the time picker will not behave as expected. Discover may load, but time-based filters will not filter correctly.

Choose the data view shape before choosing the field

Two structural decisions matter as much as the field itself:

• Avoid one giant wildcard across dozens of indices. A wildcard data view can slow field-list loading and search performance. Prefer date-named index patterns, data streams, or ILM rollover aliases so Kibana queries smaller, relevant subsets.
• Pick a field with real timestamps. Common candidates are @timestamp, event.created, or timestamp. Confirm the field type is date in Elasticsearch mapping before saving the data view.

Worked example: create and verify a data view

Run these steps in the Kibana UI, not a terminal. You need access to Stack Management, typically through a role with the manage_data_views or equivalent cluster privilege.

1. Open Stack Management > Data Views (or Index Patterns in older Kibana versions).
2. Click Create data view.
3. Enter a name that matches your indices or data stream, for example logs-app-* or logs-app-default-*.
4. Select the time field from the dropdown. Choose a date field such as @timestamp.
5. Save the data view.
6. Open Discover, select the new data view, and open the time picker. Confirm the field appears and that choosing 'Last 15 minutes' returns documents.
7. Save a search with a relative range, close Discover, reopen the saved search, and confirm the time filter still applies.

Risk: Changing the time field on a data view that dashboards already use can break those dashboards. Test in a space or cluster where no production dashboards depend on the data view.

Check saved-object references with the API

Dashboards store a reference to the data view ID, not just the name. If you delete and recreate a data view with the same name, the ID changes and dashboards can become orphaned. You can inspect this with the Kibana Saved Objects API.

Run from a terminal with network access to Kibana. You need a Kibana session token or API key with permission to read saved objects.

curl -s -H "kbn-xsrf: true" "https:///s//api/saved_objects/dashboard/" | python3 -m json.tool

Placeholders:

• KIBANA_URL: your Kibana endpoint, such as localhost:5601.
• SPACE_ID: the Kibana space, default is default.
• DASHBOARD_ID: the saved dashboard ID from its URL.

Expected check: Look for a dataViewId or index-pattern reference in the returned JSON. Compare it to the ID shown in Stack Management > Data Views. If they differ, the dashboard points to a stale data view.

Risk: This is a read-only GET request. Do not use PUT or POST on saved objects unless you have tested the change in a non-production space.

Limitations and how to verify the result

Changing a data view's time field after dashboards exist can break saved searches, visualizations, and dashboard time ranges because stored queries reference the field. Deleting and recreating a data view with the same name does not restore old references; the new data view has a new ID.

Practical verification after any change:

1. Open Stack Management > Data Views and confirm the selected time field appears in the Discover time picker.
2. Save a search with a relative time range, reopen it, and confirm the time filter applies to the chosen field.
3. Use the Saved Objects API to inspect a dashboard's data view reference and compare it to the current data view ID.
4. In a test cluster, delete and recreate a data view with the same name and confirm existing dashboards no longer load until references are updated.

Wildcard data views over many indices can also slow field-list loading. If Discover feels sluggish, switch to a data stream or ILM alias and measure field-list load time before and after.

Closing checklist

• Select a date field, not an ID or keyword, as the time field.
• Verify the time picker in Discover before saving dashboards.
• Treat the data view ID as permanent; changing it breaks saved-object links.
• Prefer data streams or date-named indices over broad wildcards.
• Check dashboard references with the Saved Objects API after any data view change.

Get the time field right once, and the time picker, saved searches, and dashboards will keep working. Change it later, and you are editing every dependent saved object by hand.