I know this is an old message and you probably figured it out by now, but just in case... The "stats" command can turn multiple events into 1 event.  You're using list() which will create mv (multi-valued) fields.  To illustrate, you started with: status ... event 1: good ... event 2: bad ... event 3: good ... event 4: bad ... When you do a search like: | stats list(status) as status, ..., you end up with: status event 1: good bad good bad So the coloring is for 1 "cell", not 4 "cells".   ... View more

I know what the issue is. It is explained here: https://www.splunk.com/en_us/blog/tips-and-tricks/cannot-search-based-on-an-extracted-field.html Here is the way I understand it. Splunk automatically indexes word tokens, which are detected using "standard" delimiters like spaces, tabs, commas, etc. Here is what most people don't know or understand: even though you specify a search like so (in your example): index=blah Service="examplename" What Splunk actually does initially is a search like this: index=blah "examplename" Under normal circumstances, this works fine - and it normally returns a "super set" of the results you are looking for. Then, Splunk refines the results further with a search like this: | search Service="examplename" Which should reduce the data set down to the specific results you are looking for. What went wrong here? Well, your data doesn't have the standard word boundary delimiters Splunk expects. In your case, there are tilde characters around the word you want to search on, so the "examplename" string doesn't match, but the "*examplename" does. How can you fix this? I think you have two choices: 1) Don't use tildes as delimiters! Actually, don't use any non-standard delimiters. But we don't always have control over that, so... 2) If you know you have this issue with your data, create a fields.conf file in the same app that contains your props.conf, and set it like this (NOTE: replace "fieldname" below with the actual fieldname!): [fieldname] INDEXED_VALUE = false But don't arbitrarily do this for all of your fields - as it can make your searches less efficient. ... View more

I had a similar problem - I have some key lookup files that I never want to be empty, because when they become empty, they can wreak havoc on my dashboards! Reasons why they might become empty: low disk space or application issues (i.e., not normal situations). To protect against this, I modified my automated lookup searches as follows: <search that builds my_lookup.csv> | eval new=1 | append [|inputlookup my_lookup.csv | eval new=0] | eventstats sum(new) as newCount | eval useNum=if(newCount>5,1,0) | where new=useNum | fields - new newCount useNum | outputlookup my_lookup.csv What I like about my solution is it will exclusively use the new data if it exists and fall back to the old data if the new data has less than 5 events (i.e., there is no "merging" of the new and old data, which can cause issues if data has been deleted.) ... View more