You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Maintain relative date selection for saved/linked searches #3567
Currently when saving a search no "relative date selection" info is saved.
Meaning that when clicking the link of the search, it will open in Live Tail always.
What would you like to see?
Many of the dashboards/query would benefit from being able to save that they're intended to be viewed over a "relative amount of time" (last day, last week, like its possible to select from daterange selection)
Workaround
I'm currently including AND Timestamp >= subtractDays(now64(), 1) AND TimestampTime <= now64() in my query to make sure it always selects the last day of data
I think taking a page from how grafana does it is cool, when saving a dashboard/query it asks you if the settings of the datetime are to be saved as default view with the dashboard.
Problem is at the moment it seems when you select the relative time from dropdown there is no info saved about the relative time change, it calculates the difference and just sends it.
Kibana keeps the relative time when you select it:
This makes sense. However, before we do this implementation it would be worth proposing a plan on how we can implement this, as the change could be fairly large and requires forward thinking. Open to contributions if you're interested 😄
Storage: add savedDateRange to saved searches, using the same shape dashboards already have (#3073): { type: 'relative', value: seconds } | { type: 'historical', value: [startMs, endMs] }. Both would share one extracted schema. The field is optional, so no migration.
Opening: if the URL has no time, a stored range opens as [now − N, now] with live tail off, the same as dashboards. Live tail can't do ranges longer than 6h, so it can't cover "last day" or "last week". Links that already carry a time (alerts, shared URLs) still win.
Saving: the save modal gets a "When opened" option: live tail, keep the saved range, or use the current range (only offered when it ends now).
Later PRs: keep the range relative in the URL so copied links stay "last 1 day"; external API, MCP and CLI support; dashboards (#2254).
Questions:
Should the field be savedDateRange (as on dashboards) or defaultTimeRange (as in #2254)?
Is a fixed window OK for ranges of 6h or less too, or should those open as live tail?
Opened #3593. It uses defaultTimeRange and only accepts relative ranges ({ type: 'relative', value: }), so absolute date windows can't be saved.
Small note: dashboards currently store this as savedDateRange in code, so I left that one as is to avoid a migration. Happy to align it in a follow-up if you'd like.
Activity
brandon-pereira commentedon Nov 5, 2026
This makes sense, how would you propose we store these settings in docdb?
czephyr commentedon Nov 6, 2026
I think taking a page from how grafana does it is cool, when saving a dashboard/query it asks you if the settings of the datetime are to be saved as default view with the dashboard.
Problem is at the moment it seems when you select the relative time from dropdown there is no info saved about the relative time change, it calculates the difference and just sends it.
Kibana keeps the relative time when you select it:
brandon-pereira commentedon Nov 6, 2026
This makes sense. However, before we do this implementation it would be worth proposing a plan on how we can implement this, as the change could be fairly large and requires forward thinking. Open to contributions if you're interested 😄
Asheesh7298 commentedon Nov 6, 2026
I'd like to take this. Proposed plan:
Storage: add savedDateRange to saved searches, using the same shape dashboards already have (#3073): { type: 'relative', value: seconds } | { type: 'historical', value: [startMs, endMs] }. Both would share one extracted schema. The field is optional, so no migration.
Opening: if the URL has no time, a stored range opens as [now − N, now] with live tail off, the same as dashboards. Live tail can't do ranges longer than 6h, so it can't cover "last day" or "last week". Links that already carry a time (alerts, shared URLs) still win.
Saving: the save modal gets a "When opened" option: live tail, keep the saved range, or use the current range (only offered when it ends now).
Later PRs: keep the range relative in the URL so copied links stay "last 1 day"; external API, MCP and CLI support; dashboards (#2254).
Questions:
Should the field be savedDateRange (as on dashboards) or defaultTimeRange (as in #2254)?
Is a fixed window OK for ranges of 6h or less too, or should those open as live tail?
brandon-pereira commentedon Nov 6, 2026
Great, thanks @Asheesh7298 !
Agreed on same approach as #3073.
Let's please use
defaultTimeRangeto match dashboards.IMO we should not allow fixed windows, I don't see a use case for this (yet), lets keep that out.
Asheesh7298 commentedon Nov 7, 2026
Thanks! @brandon-pereira
Opened #3593. It uses defaultTimeRange and only accepts relative ranges ({ type: 'relative', value: }), so absolute date windows can't be saved.
Small note: dashboards currently store this as savedDateRange in code, so I left that one as is to avoid a migration. Happy to align it in a follow-up if you'd like.