How to get results to load with a time picker setting other than "All Time" for saved search results loaded via loadjob?



I have a saved search that summarizes data for the entire year to date. Currently I have a dashboard that loads the saved search results via loadjob (w/ time picker set to "All Time").

This works fine. However, now we need to allow the user to change the time range. Say the user wants to see the last 30 days instead of the whole year... If the user select Last 30 days from time picker, the saved search results do not load!

How can I get the results to load with a time picker setting other than "All Time" for saved search results loaded via loadjob?


Hello all, I am also in need of similar requirement. 

1.I have a saved search for Yesterday's date.

2. My dashboard loads by default Yesterday's date

3. When selecting Yesterday, it should pick saved search or else it should run (another report) by passing dates.

I am able to achieve this somewhat:



<set token="RepoName">Report_Yesterday</set>

<set token="Earliest"></set>

<set token="Latest"></set>


<search id="base" ref="$RepoName$">




<input type="time" token="token_time_selection" searchwhenchanged="True">

<label>Time Selection</label>


<earliest> -1d@d</earliest>




<condition match=" $token_time_selection$ ==-1d@d ">

<set token="RepoName">Report_Yesterday</set>

<set token="Earliest"></set>

<set token="Latest"></set>



<set token="RepoName">Report_Alltime</set>

<set token="Earliest">$token_time_selection.earliest$</set>

<set token="Latest">$token_time_selection.latest$</set>




This is working fine for me. However, when i change "searchwhenchanged" to false (to enable submit button) , it is not working. 

Any help would be much appreciated..

Thanks in advance



0 Karma

New Member

None of these answers work for me.

0 Karma

Path Finder

I believe you are forcing your query to have earliest="" and latest="" to search results ? if yes. then i think above examples dosn't work.
I am facing the same problem and if i remove earliest latest from search query then use above examples its working. can able to use timepicker in dashboard, moreover if i remove earliest and latest from query and search results for last 6 months i only get data for last 3 months not more than that.
thats why have to force query to serach results using earliest annd latest.
(ex., index=test sourcetype=test1 earliest=-6mon@mon latest=@mon |table _time conferences id name number)
any help?

0 Karma


And a step further to handle both use cases of absolute date range and relative. In this case time picker is called timerange

    <query>| loadjob savedsearch="username:APP:searchname" 
| eval start_time_rel=relative_time(now(),"$timerange.earliest$")
| eval end_time_rel=relative_time(now(),"$timerange.latest$")
| eval start_time=coalesce(start_time_rel,"$timerange.earliest$")
| eval end_time=coalesce(end_time_rel,"$timerange.latest$")
| where _time>=start_time AND _time<=end_time</query>

I am sure there is a better way to do this (setting tokens or something) but this is what I cobbled together for now.


@csendekw's answer would'nt work for me, it wouldn't parse the relative times in the where function

I managed to do it using the relative_time function for use in a dashboard with a timepicker input.

<query>| loadjob savedsearch="foo:bar:buzz" | eval start_time=relative_time(now(),"$token_time.earliest$") | eval end_time=relative_time(now(),"$token_time.latest$") | where _time>=start_time AND _time<=end_time </query> 



I just ran in to this problem today. My solution was to do this:

| loadjob "job" | where _time>$time_tok.earliest$ AND _time>$time_tok.latest$

It's worth noting that sometimes it seems like loadjob will return fields in an unexpected order. You can reevaluate field order like this:

| loadjob "job" | fields _time field1 field2 | where _time>=$time_tok.earliest$ AND _time<=$time_tok.latest$

This will put fields back in order for you.

This all of course assumes your time picker is named time_tok

Path Finder

I downvoted this post because this doesn't actually work and i'm guessing the poster didn't verify prior to posting.

0 Karma


Literally just tested this. Works fine. Some minor changes I had to make (probably something changed between splunk versions:
|loadjob 1511986285.448773 | where _time < "$timepicker.latest$" AND _time > "$timepicker.earliest$"

Had to put quotes around the token. I had 24 hours of data in the job, but was able to narrow it using a dashboard time picker down to 60 minutes or 4 hours or whatever arbitrary time period i put.


I should also note, _time is part of the search results (and I was hoping the timepicker would work off that, but looks like it doesn't). Can I somehow convert these results into "raw events" so that _time is picked up like usual? Just trying to think of ways to make this work without using a data model (this saved search runs "transaction" over a year-long timespan, which would take forever even with datamodel, and I'd rather not set up summary index if I don't have to).

0 Karma


I want to say "you can't do that", because the time picker defines the interval for a search to run when the search is dispatched. In the case of doing a loadjob the search was already dispatched, and you are just pulling in the artifact. A better solution here might be an accelerated data model instead of a saved search, or a summary index if you like old school or have reasons for using a summary index like retention of the summary longer than the source data.

But, maybe someone will come along and prove me wrong 🙂

Get Updates on the Splunk Community!

Splunk Forwarders and Forced Time Based Load Balancing

Splunk customers use universal forwarders to collect and send data to Splunk. A universal forwarder can send ...

NEW! Log Views in Splunk Observability Dashboards Gives Context From a Single Page

Today, Splunk Observability releases log views, a new feature for users to add their logs data from Splunk Log ...

Last Chance to Submit Your Paper For BSides Splunk - Deadline is August 12th!

Hello everyone! Don't wait to submit - The deadline is August 12th! We have truly missed the community so ...