# Watcher / Alerting: Time issues with frequent watch
**URL:** https://discuss.elastic.co/t/watcher-alerting-time-issues-with-frequent-watch/68710
**Category:** Elasticsearch
**Created:** [December 12, 2016, 12:05pm UTC](https://discuss.elastic.co/t/watcher-alerting-time-issues-with-frequent-watch/68710 "2016-12-12T12:05:53Z")
**Posts on this page:** 1
**Showing post:** 3
### Author:  [@skearns](https://discuss.elastic.co/u/skearns)
#### Post date: [December 14, 2016, 3:38am UTC](https://discuss.elastic.co/t/watcher-alerting-time-issues-with-frequent-watch/68710/3 "2016-12-14T03:38:23Z")
There might be another solution. It is a bit awkward, and won't work for all situations, but is worth mentioning.
The Chained Inputs feature of Watcher allows you to run more than one input. You could use the HTTP input to run a [field stats](https://www.elastic.co/guide/en/elasticsearch/reference/5.1/search-field-stats.html) request against the time-field of interest - this will show you the _actual_ date range that currently exists in the searchable index, which would account for the time lag in getting the data processed, sent to ES, and the refresh period that @spinscale mentions.
Then your second input could be the search you're doing now, but instead of now-5s, you would do \-5s. This would be considerably more robust.
If you wanted to account for bursts or backups in indexing, you could also consider extending the "lookback" period, and using throttling to ensure that you don't send too many notifications.
---
_[View the full topic](https://discuss.elastic.co/t/watcher-alerting-time-issues-with-frequent-watch/68710)._