A MikroTik router keeps its own clock, and out of the box that clock is only as accurate as whatever time it had when it booted — it can drift by minutes or more over weeks of uptime, especially on boards without a battery-backed real-time clock. That doesn't sound urgent until you're staring at a log timestamp that doesn't line up with the rest of your infrastructure, or a certificate validation that fails because the router thinks it's a different day.
Open the NTP client settings
In WinBox, go to System > NTP Client. From the CLI, the same thing is one command.
Enable the client and set NTP servers
Point it at a public NTP pool — pool.ntp.org resolves to different servers on each lookup, which is exactly what you want for redundancy:
/system ntp client set enabled=yes servers=0.pool.ntp.org,1.pool.ntp.orgSet the correct time zone
NTP syncs the router to UTC internally; the time zone setting only affects what's displayed in logs and the terminal. Set it once so your logs read in local time instead of UTC:
/system clock set time-zone-name=America/Argentina/Buenos_AiresConfirm it synced
Check the client status — status should read synchronized, not waiting or a stale value:
/system ntp client printWhy do it this way
An accurate clock isn't cosmetic — TLS certificate validation, log correlation, and RADIUS/PPP accounting timestamps all depend on it silently working correctly. The failure mode is the worst kind: nothing breaks obviously, until the one time you're mid-incident trying to line up this router's log against a switch's log against a server's log, and the timestamps don't agree because one of them drifted. Enabling NTP once, at setup time, costs nothing and removes that entire category of "why don't these logs match" debugging later.
How MoniTik helps
MoniTik timestamps everything it records — alerts, connection history, interface graphs — using its own clock, not the router's, so a drifted router clock won't desync what you see in the dashboard. But MoniTik can go further: a future check that flags a router whose reported clock has drifted noticeably from real time is exactly the kind of "you'd never notice until it bites you" problem monitoring is meant to catch before you do, the hard way, mid-incident.
Camila focuses on routing, VPNs, and hardening MikroTik deployments for small and mid-size networks.