← Back to Blog

Unix Timestamp Conversion for Incident Timelines and Log Correlation

Utility · June 2, 2026 · 5 min read

When an incident spans multiple systems with different timestamp formats, Unix timestamps are the universal translator. Build accurate timelines fast.

Technical cover image for Unix Timestamp Conversion for Incident Timelines and Log Correlation

Three Systems, Three Time Formats, One Incident

Your database logs in ISO 8601. Your CDN logs in Unix timestamps. Your application logs use a human-readable format with the local timezone. When an incident spans all three, building a timeline means converting everything to one format. Unix timestamps are the universal pivot — they are timezone-independent and monotonic.

Use OpsCheck Timestamp Converter to convert between Unix timestamps and human-readable dates instantly. Pair it with OpsCheck Email Header Analyzer when the incident involves email delivery delays, which often use their own timestamp formats.

Converting Between Formats

# Unix timestamp → human readable
date -d @1710000000
# Output: Sat Mar 09 12:00:00 UTC 2026

# UTC explicitly
date -u -d @1710000000

# Human readable → Unix timestamp
date -d "2026-06-11 14:30:00 UTC" +%s

# ISO 8601 → Unix timestamp
date -d "2026-06-11T14:30:00Z" +%s

Building an Incident Timeline

# Extract CDN log timestamps (Unix format, column 1 in this example)
awk '{print $1}' cdn-access.log | while read ts; do
  echo "$ts → $(date -u -d @$ts '+%Y-%m-%d %H:%M:%S UTC')"
done | head -20

# Correlate application logs by time window
# Application log format: 2026-06-11 10:23:45,123 ERROR ...
# Convert to Unix for comparison
grep "2026-06-11 10:2[3-5]" app.log | head

# journalctl with time window
journalctl --since "2026-06-11 10:00:00" --until "2026-06-11 10:30:00" -u nginx

Real-World Scenario

An incident report said "users started seeing 502 errors at 10:25 UTC." The CDN logs showed backend timeout errors starting at Unix timestamp 1710000000. The application logs showed a database restart at "2026-06-11 12:23:45 CEST." Converting everything: CDN timestamp 1710000000 = 2026-06-11 10:20:00 UTC. The database restart at 12:23 CEST = 10:23 UTC. The timeline aligned: database restart at 10:23 UTC, first CDN timeout at 10:20 UTC (connection pool exhaustion started before the actual restart), widespread 502s at 10:25 UTC. The OpsCheck HTTP Headers confirmed the 502 responses had the correct timing.

# Quick incident window: convert boundaries to Unix
START=$(date -d "2026-06-11 10:00:00 UTC" +%s)
END=$(date -d "2026-06-11 10:30:00 UTC" +%s)
echo "Incident window: $START to $END (Unix timestamps)"

Timeline Checklist

  • Convert ALL log sources to Unix timestamps first — it is the common denominator
  • Always use UTC for human-readable conversions to avoid timezone confusion
  • Add timezone offset to your incident notes: "10:25 UTC (12:25 CEST)"
  • Use OpsCheck Timestamp Converter for quick spot checks
  • When correlating logs from different systems, pad your time window ±5 minutes for clock skew