Some Elasticsearch indices do not use @timestamp as their time field. In Kibana, ES|QL can still work with the time picker when your query compares the correct date field to the ?_tstart and ?_tend parameters.
FROM kibana_sample_data_ecommerce
| WHERE order_date >= ?_tstart AND order_date < ?_tend
| STATS orders = COUNT(*), revenue = SUM(taxful_total_price) BY customer_gender
| SORT revenue DESC
Why this ES|QL pattern helps
Kibana visualizations and Discover sessions are more useful when they respond to the global time picker. This pattern connects ES|QL to the selected time range even when the index uses a business date such as order_date, event.ingested, or transaction.time.
What to change for your data
- Replace
order_datewith the date field that should drive the analysis. - Use
< ?_tendfor the upper bound to avoid overlap when adjacent time windows are compared. - Keep the time filter near the start of the query so fewer rows flow into later processing steps.
When to use it
This is useful for Kibana ES|QL dashboards, business data sets, ecommerce analytics, custom application events, and any support case where the time picker appears inactive because the index has no standard @timestamp field.
Source reference: Elastic documentation: ES|QL and time series data in Discover.
