🚨 VictoriaMetrics Error: 'cannot parse timestamp' — Cause, Fix, and Troubleshooting Guide

Overview

Every sample VictoriaMetrics ingests carries a timestamp, and the parser sanity-checks it against the current time. A value far in the future is almost never a real timestamp — it is a precision mistake, where the client sent seconds where milliseconds were expected (or milliseconds where nanoseconds were), inflating the number by orders of magnitude. VictoriaMetrics rejects it:

cannot parse timestamp "1717200000000000000000": too big timestamp; it must be smaller than the current time; probably wrong precision (seconds vs milliseconds)

The parser is telling you the value is too large to be a plausible time, and it even guesses the cause. Different ingestion paths expect different precisions — the Prometheus import path expects epoch milliseconds, while Influx line protocol carries an explicit precision on the request — so a client using the wrong unit produces a timestamp that overshoots “now” by years or millennia.

Symptoms

• Ingest logs show cannot parse timestamp "...": too big timestamp and the sample is dropped.
• Data from one Influx, Graphite, or import client never lands, while other sources ingest fine.
• The rejected timestamp has far more digits than a normal epoch value for the unit involved.
• Samples appear with wildly wrong times (far future) when a client does slip through with a different mismatch.
• A newly added exporter or push script fails immediately on its first write.

Common Root Causes

• Wrong precision — seconds sent where milliseconds are expected, or milliseconds where nanoseconds are expected, multiplying the value out of range.
• Non-numeric or garbage timestamp — a stray character or a formatted date string where an epoch integer belongs.
• Malformed Influx line-protocol line — fields in the wrong order, so a value is read as the timestamp (or vice-versa).
• Client default mismatch — an Influx client defaulting to nanosecond precision talking to an endpoint configured for a different unit.

How to diagnose

Compare the rejected value against the current epoch in the expected unit to see how far off the precision is:

# Current time in seconds and in milliseconds for reference
date +%s
date +%s%3N

A plausible epoch-millisecond timestamp today is 13 digits; the rejected 1717200000000000000000 is 22 digits — roughly a billion times too large, the classic seconds-as-nanoseconds mistake. Reproduce with a correctly-scaled value to confirm the endpoint is fine:

# Prometheus import expects epoch MILLISECONDS as the 2nd field
NOW_MS=$(date +%s%3N)
printf 'up{job="test"} 1 %s\n' "$NOW_MS" \
  | curl -s --data-binary @- 'http://localhost:8428/api/v1/import/prometheus'

Fixes

1. Use epoch milliseconds for the Prometheus import path. When pushing to /api/v1/import/prometheus, the optional timestamp must be epoch milliseconds. Multiply seconds by 1000 (or divide nanoseconds by 1e6) before sending.

2. Set the correct Influx precision on the client. Influx line protocol carries a precision parameter; make the client’s precision match the timestamps it actually emits (ns, us, ms, or s) so VictoriaMetrics scales them correctly.

# Tell the Influx write endpoint the timestamps are in seconds
curl -s "http://localhost:8428/write?precision=s" \
  --data-binary 'cpu,host=web1 usage=0.42 1717200000'

3. Validate the line-protocol format. Ensure each Influx line is measurement,tags fields timestamp with the fields in that order; a shifted column makes a value get parsed as the timestamp.

4. Fix field ordering in the client. For any import format, confirm metric, value, and timestamp map to the right positions the endpoint expects, so a value is never misread as a time.

What to watch out for

• Count the digits: a today-epoch is 10 digits in seconds, 13 in milliseconds, 19 in nanoseconds — a big mismatch is an instant precision tell.
• The error only says “too big” because a future timestamp is implausible; the same root cause can also yield timestamps that are wrong-but-accepted, so fix the precision even when ingestion does not error.
• Influx precision is per-request — one misconfigured client can corrupt times while every other source looks correct.
• A malformed line-protocol line can shift columns silently; validate format before assuming a precision bug.

Related

• VictoriaMetrics Error Guide: too old timestamp
• VictoriaMetrics Error Guide: cannot parse labels
• VictoriaMetrics Error Guide: cannot parse MetricsQL