What us= means in an OpenVPN log line, and how to convert it

OpenVPN's text log puts a date, a time, and a us= value on the same line, and the last of the three is the part readers misread. It is the microsecond component of that timestamp, printed without zero padding. It is not a session identifier, a user name, or a counter, and treating it as one turns a fraction of a second into a confident wrong conclusion. Convert it as a fraction of the displayed second and the rest of the line stays readable.

What the three parts of the line mean

The date and whole second come first, and us= carries the remainder below one second. A value of 12345 is twelve thousand three hundred forty-five microseconds, which is 0.012345 seconds, so the line describes 09:15:30.012345 when the printed time is 09:15:30. The counter restarts with every new second, so a later line can print a smaller fraction without any clock running backwards. Only the complete timestamp orders events.

2026-11-02 08:41:07 us=4820

The unit is one millionth of a second, and six digits of us= cover the whole range from 0.000000 to 0.999999. Five digits describe tens of milliseconds, while six describe hundreds of milliseconds up to nearly a full second. If a conversion produces a fraction larger than one, the decimal point moved and the arithmetic is wrong. Doing it by hand means dividing the printed integer by one million and adding it to the whole second.

Padding is the trap. us=42 is forty-two microseconds, written .000042, not .42. Pad the integer to six places on the left before converting, and the value stops looking like a decimal fraction of the digits you see.

Converting a line without a calculator

Take the printed second as the base and treat us= as the fraction. For 09:15:30 with us=12345, the decimal form is 09:15:30.012345; for us=900000, it is 09:15:30.900000. The digits after the decimal point are the padded integer, never the integer divided by a thousand. Writing the six-digit form first prevents most mistakes.

If you parse logs into timestamps, parse the date, the whole second and the fraction together. A parser that assumes milliseconds will order events wrongly by a factor of a thousand, and the output still looks plausible.

When the field is missing from the log

The microsecond part belongs to the text log format and appears only when detailed timestamps are enabled. In OpenVPN 2.6's timestamp formatter, it is appended when that output is on and the stored value is nonzero. A log without us= therefore says nothing about the clock or the build; it usually means the configured verbosity is too low. Check the configuration before you blame time synchronisation.

The setting is easy to confirm from the server configuration. Run the command below and read the number it returns. Detailed timestamp output appears at verbosity 4, so a lower value explains the missing field without any other fault. Running the same configuration with --verb 4 shows the field once the daemon restarts with that level.

grep -nE '^[[:space:]]*verb[[:space:]]+[0-9]' /etc/openvpn/server.conf

Raising verbosity adds detail to the log; it does not improve the clock. After the restart, compare a new line with an old one to confirm the format changed, and lower the level again once the question is answered.

What six digits do not prove

Six digits describe resolution, and resolution says nothing about whether two hosts agree on the time. A client and a server can both print microseconds while their clocks differ by seconds. When you correlate events across machines, record the time zone and any known offset, and prefer a field that names the peer or the session over any timestamp. Two lines that share a fraction are not necessarily the same connection.

A collector may stamp each line on arrival, which adds a second timestamp that belongs to the collector rather than to OpenVPN. Identify which one you are reading before comparing them, and keep the raw line so the comparison can be redone.

A fresh us= value does not prove that a new client logged in, and a repeated one does not prove a duplicate event. The peer and connection fields answer those questions.