Read Unix Timestamps in Server Logs and Find When It Broke

What the number means

A Unix timestamp counts the seconds since 1 January 1970 00:00:00 UTC. The value 1767225600 is 1 January 2026 at 00:00:00 UTC. Because the epoch is anchored to UTC, the same number means the same instant everywhere, and only its display changes with the time zone.

Seconds or milliseconds

The most frequent mistake is a unit mismatch. A current timestamp in seconds has 10 digits. One in milliseconds, as used by JavaScript Date.now() and many logging libraries, has 13 digits. If you paste a 13-digit value as seconds, you get a date thousands of years in the future. Match the unit to the digit count, and the converter offers both.

Trace an incident step by step

1. Find the first error line and copy its timestamp.
2. Paste it into the converter and choose seconds or milliseconds to match the digit count.
3. Read the result in UTC, then in your local time zone.
4. Repeat for the last normal log line before the failure.
5. Compare the gap with deploy times, scheduled jobs and traffic changes to find what happened in between.

Common gotchas

• Servers in different regions may log local time instead of epoch time, so check the format first.
• Daylight saving changes shift local times by an hour twice a year, which is why UTC is safer for comparison.
• Some systems store fractions such as 1767225600.250 for sub-second precision.
• Values like 0 or 1970-01-01 usually mean an uninitialized field, not a real event.
• Very large values, such as 16 digits, may be microseconds and need dividing by 1,000,000.

Converting in the other direction

You can also start from a date. If an incident started on 15 March 2026 at 14:30 UTC, convert that date and time to a timestamp (the converter reads the date in your browser's local time zone, so shift it by the offset when the incident time is in UTC), then search the logs for entries near that number. Searching for a range works well: compute the timestamp for the start and the end, and filter lines between them with your log tool. Remember to include the time zone when entering a local time, or the result will be off by the offset.

Check your own tooling

If you write the logs yourself, log timestamps in UTC and in ISO 8601 form, such as 2026-01-01T00:00:00Z, next to or instead of the raw epoch value. Epoch numbers are fine for storage but poor for humans reading a terminal at 3 a.m. When you receive logs from a vendor, ask which unit and zone they use before building an investigation on them. A ten-minute misunderstanding about units can send you looking at the wrong deployment entirely.

Write a note others can follow

When you share findings, include both the raw timestamp and the readable UTC time, for example 1767225600 (2026-01-01 00:00:00 UTC). That removes any doubt about the time zone and lets colleagues paste the number into their own tools to verify. It also makes post-incident timelines far easier to assemble, because every entry has one unambiguous reference.