It depends on how/where you change it and what you settings you are trying to invoke (which parser handles them). If you "change" it with rename , which is a search-time operation, then definitely not do anything at all. The Splunk_TA_paloalto TA from SplunkBase take stuff that comes in with sourcetype=pan:logs and breaks it out (successfully) like this: From props.conf: [pan:log] TRANSFORMS-sourcetype = pan_threat, pan_traffic, pan_system, pan_config, pan_hipmatch, pan_endpoint From transforms.conf: [pan_threat] DEST_KEY = MetaData:Sourcetype REGEX = ^[^,]+,[^,]+,[^,]+,THREAT, FORMAT = sourcetype::pan:threat And then later in props.conf for some stuff: [pan:threat] TIME_PREFIX = ... REPORT-foo... FIELDALIAS-foo ... EVAL-foo ... LOOKUP-foo ... The bottom line, though, is that you are never going to get a second change to go through the TRANSFORMS- parser unless you cook it twice (Index it twice). Once it has been cooked, the only decision to be made is where to write it to disk. Can you transform it with syslog-ng before sending it to Splunk (this is a very common way to handle this kind of thing)? Another possibility might be manipulation with HTTP Event Collector ; as I recall, it is very special in how it cooks the data. ... View more

Some thoughts... It could be that your snapping is confusing the issue (e.g. it 'snapping' to minute or other time boundaries). Could you try ns="article.load" earliest=-40m@m latest=-15m@m | where geoCity=="LONDON" | transaction txid maxspan=30m maxpause=30m | eventstats perc95(duration) as perc | where duration < perc Then vary earliest and latest and compare results. earliest=-35m@m latest=-10m@m earliest=-30m@m latest=-5m@m etc... As long as you run them within a minute or so, they should all return reasonable results - check the timeline to see how they fall and if they're fairly consistent. Another thing that may be happening is that 40 minutes is longer than your maxspan and maxpause, whereas 10 minutes is shorter. This can subtly (and not so subtly) alter results. If you always run all searches older than 30 minutes, you should always get consistent results so try checking various timeframes older than 30 minutes. Note, you should be able to skip | where geoCity=="LONDON" | ... because you should be able to ns="article.load" earliest=-2h@h latest=-1h@h geoCity=="LONDON" | transaction txid maxspan=30m maxpause=30m | eventstats perc95(duration) as perc | where duration < perc Probably, anyway. 🙂 ... View more