# Timestamping issues with Winlogbeat and Logstash **URL:** \ **Category:** Beats\ **Created:** [June 30, 2020, 2:39pm UTC](https://discuss.elastic.co/t/timestamping-issues-with-winlogbeat-and-logstash/239325 "2020-06-30T14:39:52Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Jasonespo](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@Jasonespo](https://discuss.elastic.co/u/Jasonespo)\ **Post date:** [June 30, 2020, 2:39pm UTC](https://discuss.elastic.co/t/timestamping-issues-with-winlogbeat-and-logstash/239325/1 "2020-06-30T14:39:52Z")
Hello, Our setup is: Winlogbeat on endpoints which ships data to an API API sends logs to sqs queue Logstash VM picks up from sqs and contextualises logs then forwards them on to another sqs queue Another application processes those logs and indexes them into ES Our issue is that the @timestamp value that is being indexed into Elasticsearch is at a later date than the event.created value. Which means that the processed time is BEFORE the event occured on the endpoint (which is obviously incorrect) Based on this statement: ``` event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. ``` Could it be that our logstash VM that sits in the middle of the Winlogbeat agents and Elasticsearch is updating the @timestamp value to be the time that logstash processes it and not the time that the original event occurred on the endpoint? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 28, 2020, 4:40pm UTC](https://discuss.elastic.co/t/timestamping-issues-with-winlogbeat-and-logstash/239325/2 "2020-07-28T16:40:04Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.