Timestamp is Ingest Time

[RusFM]

Wazuh Community,

When issues occur on the server (e.g. high watermark) and logs stop being ingested, but are ingested later, the timestamp in OpenSearch is the ingest time, not the alert time.

Example from /var/ossec/logs/alerts/alerts.log (the JSON is reformatted for readability)-

** Alert 1766431725.176018647: - hmailserver,
2025 Dec 22 14:28:45 wazuh->/var/log/mail.json
Rule: 540231 (level 3) -> 'Sending Email'
Src IP: 192.168.0.17
Dst IP: 192.168.0.17
{
    "action": "Send",
    "dsthostname": "mail.thedomain.local",
    "dstip": "192.168.0.17",
    "extra_data": "sys...@thedomain.com > alert...@somewhere.com",
    "id": "2409118",
    "message": "SMTPDeliverer - Message 2409118: Delivering message from sys...@thedomain.com to alert...@somewhere.com. File: C:\\Program Files (x86)\\hMailServer\\Data\\{B4596D57-188A-4866-81F0-21877E57986D}.eml",
    "srchostname": "mail.thedomain.local",
    "srcip": "192.168.0.17",
    "timestamp": "2025-12-22T05:17:23.698Z",
    "type": "hmailserver",
    "url": "C:\\Program Files (x86)\\hMailServer\\Data\\{B4596D57-188A-4866-81F0-21877E57986D}.eml"
}
message: SMTPDeliverer - Message 2409118: Delivering message from sys...@thedomain.com to alert...@somewhere.com. File: C:\Program Files (x86)\hMailServer\Data\{B4596D57-188A-4866-81F0-21877E57986D}.eml
type: hmailserver
srchostname: mail.thedomain.local
timestamp: 2025-12-22T05:17:23.698Z
dsthostname: mail.thedomain.local

The JSON has the actual log with the timestamp and is parsed correctly into the timestamp field (2025-12-22T05:17:23.698Z).  But the top of the alert and in OpenSearch the timestamp is the ingest time (2025 Dec 22 14:28:45).

How can I fix this?

Thanks,

Rus

[Javier Rosas]

Hello Rus

Let me check internally, and I will get back to you

[Javier Rosas]

Hello again.

Not sure I follow this. The @timestamp field differs from the date of the log?
This could be due to timezone differences. Also, both the agent and the manager have input queues that can be overflowed.

https://documentation.wazuh.com/current/user-manual/agent/agent-management/antiflooding.html#use-case-leaky-bucket

Alerts with rule.ids 202 203 and 204 will usually be triggered when these limits are met.

[Javier Rosas]

Hi Rus,

What you are seeing is expected behavior and is related to the difference between event time and ingest time.

By default, OpenSearch sets the @timestamp field to the ingest time, meaning the moment the document is received and indexed by OpenSearch. When ingestion is delayed due to issues such as high disk watermark, queue backlogs, or resource pressure, the documents are indexed later, and @timestamp reflects that later time.

The original event time is not lost. As you noticed, the JSON alert still contains the correct timestamp from the log itself. However, unless an ingest pipeline explicitly parses that field and assigns it to @timestamp, OpenSearch will continue using ingest time.

The timestamp shown at the top of the alert (and in OpenSearch visualizations) is therefore not the alert creation time, but the indexing time. Disk or queue issues only increase the delay; they do not change how @timestamp is assigned.

https://docs.opensearch.org/latest/ingest-pipelines/processors/date/

https://docs.opensearch.org/latest/data-prepper/pipelines/configuration/processors/date

[RusFM]

Apologies Javier, I didn't receive any notifications you'd replied.

I'll check into potential pipeline changes and circle back.

Rus