Timestamp 2025-06-26T17:50:51.093Z is not taken, server time written instead

[Balvert]

We had issues that the time in SEQ was not correct, and we did a Postman test. When we send this to postman, SEQ takes the server time, but the format is correct:

{
"Events": [{
"Timestamp": "2025-06-26T17:50:51.093Z",
"Level": "Error",
"MessageTemplate": "We are on SEQ XXX",
"Properties": {
"Application": "Test",
"Environment": "Prod",
"Version" : "1.0",
"Hardwareid" : "demo12345"
}
}]
}

SEQ entry:
26 Jun 2025 17:58:57.017
We are on SEQ XXX

[liammclennan]

Seq uses the timestamp included in the event unless: the event does not include a timestamp, or Seq is configured to use server timestamps instead.

I don't think your message format is correct. I suggest using one of the available Seq client libraries.

[Balvert]

We have it repro POSTMAN, this JSON creates an entry with SERVER date/time. The second JSON uses the timestamp, screenshot of postman included.

{
"Events": [{
"Timestamp": "2025-06-27T09:05:08.123Z",
"Level": "Error", "MessageTemplate": "We are on SEQ ZZZ not ok",
"Properties": { "Application": "Test", "Environment": "Prod", "Version" : "1.0", "Hardwareid" : "demo12345" }
}]
}

[Balvert]

@liammclennan the json was included so you could see the format was correct.

[Balvert]

seq reproted this time: 2025-06-27T08:40:07.6992701Z
Server timeone is 8:40am Timezone +01 (Amsterdam).
The time "ZZZ not ok" was posted was 11:05:08

[nblumhardt]

Hi @Balvert:

seq reproted this time: 2025-06-27T08:40:07.6992701Z
Server timeone is 8:40am Timezone +01 (Amsterdam).

Those times don't appear to match - 08:40 in Amsterdam is 07:40 in GMT (Z).

11:05 is two or three hours ahead of the server time, so the timestamp drift setting mentioned above is likely to be kicking in. You can remove that behavior entirely by setting the value to a larger number.