Skip to content

Maintain relative date selection for saved/linked searches #3567

Open

Description

@czephyr

What are you trying to do?

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

Activity

  1. brandon-pereira commented on Nov 5, 2026

    @brandon-pereira
    Member

    This makes sense, how would you propose we store these settings in docdb?

  2. czephyr commented on Nov 6, 2026

    @czephyr
    Author

    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:

    Image
  3. brandon-pereira commented on Nov 6, 2026

    @brandon-pereira
    Member

    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 😄

  4. Asheesh7298 commented on Nov 6, 2026

    @Asheesh7298

    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?

  5. brandon-pereira commented on Nov 6, 2026

    @brandon-pereira
    Member

    Great, thanks @Asheesh7298 !

    Agreed on same approach as #3073.

    Let's please use defaultTimeRange to match dashboards.

    IMO we should not allow fixed windows, I don't see a use case for this (yet), lets keep that out.

  6. Asheesh7298 commented on Nov 7, 2026

    @Asheesh7298

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions