โ† Back to blog

Reading Unix Timestamps in Incident Logs

Seconds vs milliseconds, UTC vs local, and JWT exp claims - a practical guide to decoding Unix time during outages with free browser tools.

At 02:14 in an incident bridge, someone pastes a log line: expired_at=1722470400. Another engineer asks whether that is "about now" or "next week." A third person pastes a 13-digit value from a JWT and the dates jump decades apart. Reading Unix timestamps under pressure is a skill - and mixing seconds with milliseconds is the most common way teams waste the first ten minutes of a timeline review.

This guide explains what epoch values mean, how to spot seconds vs milliseconds, real incident scenarios, and how to convert them quickly with Utilitoo's browser tools without uploading sensitive logs.

What a Unix timestamp is

A Unix timestamp (epoch time) counts time since 00:00:00 UTC on 1 January 1970. Most systems store it as an integer:

FormTypical lengthExample meaning
Seconds10 digits (today)1722470400
Milliseconds13 digits1722470400000
Microseconds16 digits (less common in app logs)Database or tracing systems

The number itself has no timezone. It is an absolute instant. Timezone only appears when you display that instant as a wall-clock string for humans in New York, Berlin, or Tokyo.

Seconds vs milliseconds - the decade bug

If you treat milliseconds as seconds, converters show dates far in the future (often year 50,000+). If you treat seconds as milliseconds, you get dates near 1970.

Quick rule of thumb for 2020s incident work:

  • 10 digits - almost always seconds
  • 13 digits - almost always milliseconds
  • Floating-point with a fractional part - often seconds with sub-second precision

When two tools disagree by decades, stop debating timezone and check unit length first.

Use Unix Time Converter when you only need epoch โ†” readable date, or Timestamp Converter when you also care about timezone display and richer formatting.

Incident scenarios

API gateway 401 storm

What you see: Auth service logs token_exp=1722466800 while clients report "token expired" even though the product UI still shows a valid session.

What to do: Convert the exp claim (and iat if present) to UTC, then to each on-call engineer's local zone. Confirm whether the token expired minutes ago or the client clock is skewed. For JWT payloads, JWT Decoder shows claims; convert exp / iat with Timestamp Converter if you want city-level local times for the bridge notes.

Kubernetes crash loop with restart timestamps

What you see: Last State: Terminated with Finished At: 2026-08-01T23:58:12Z in one tool and epoch integers in another exporter.

What to do: Normalize everything to UTC first. Convert epoch fields from the metrics exporter, then compare to kubectl's RFC3339 times. Do not mix "local laptop time" screenshots with UTC log lines without labeling both.

Database created_at stored as bigint

What you see: Support asks "when did this order land?" and the warehouse table shows 1722474015123.

What to do: Count digits - this is milliseconds. Convert once, paste the UTC string into the ticket, and note the unit in the comment so the next person does not repeat the conversion with the wrong scale.

Multi-region latency review

What you see: Request IDs with start/end epoch ms from edge and origin.

What to do: Convert start and end, then compute duration carefully. For simple clock-to-clock spans (not calendar age), Time Duration Calculator helps once you have human times. For pure epoch math, subtract milliseconds first, then convert the delta to seconds.

A practical conversion checklist

  1. Copy the exact integer - no ellipsis, no rounded scientific notation from spreadsheets
  2. Count digits - decide seconds vs milliseconds before opening a converter
  3. Convert to UTC first for the timeline document
  4. Add local times only as secondary labels for humans on the call
  5. Cross-check JWT claims with JWT Decoder when the number came from a token
  6. Write the unit in the runbook (exp is seconds in JWT; your metrics SDK might be ms)

Timezones and daylight saving (DST)

Epoch conversion is not where DST usually bites you. DST bites when people schedule the next maintenance window using "same clock time next week" across cities that change clocks on different dates.

After you decode an incident timestamp:

For contractual or compliance cutoffs, verify against an authoritative clock in the relevant jurisdiction - browser tools use your device clock and IANA data, which is right for most engineering work but not a legal time source.

Privacy during incidents

Log lines often contain customer IDs, emails, or tokens next to timestamps. Prefer converting only the numeric field on Utilitoo. Timestamp Converter and Unix Time Converter run in your browser - they do not need the rest of the log line. Redact secrets before pasting anything into chat or a public ticket.

Common mistakes checklist

MistakeSymptomFix
Seconds treated as msDate near 1970Divide by 1000 or select seconds mode
Ms treated as secondsDate far in the futureUse milliseconds mode / 13-digit path
Local vs UTC unlabeledTwo engineers "disagree" by hoursAlways state the zone next to the string
JWT exp ignoredAuth looks randomDecode token, convert exp
Spreadsheet scientific notationLost low digitsPaste as plain text / full integer

Putting it together

Unix timestamps are simple integers with sharp edges. In incidents, unit confusion costs more time than timezone math. Count the digits, convert to UTC, label local times for people, and keep JWT claim decoding in the same workflow when auth is involved.

Utilitoo's Timestamp Converter, Unix Time Converter, and JWT Decoder are built for that paste-inspect-copy loop - private, fast, and available when the wiki is down and the bridge is already crowded.

Try these tools