RadiusNest › Guides

MikroTik clock wrong: set the time zone and NTP client

Last updated: 2 October 2026

Most MikroTik routers have no battery for the clock. After a power cut they wake up with an old date until something tells them the time. Two settings fix it for good: the time zone and an NTP client.

See what the router thinks

/system clock print

A date years in the past means the clock was never synchronised since the last reboot. The right date with the wrong hour means the time zone is wrong.

1. Set the time zone

/system clock set time-zone-name=Asia/Dubai

Use the name of your own region, such as Africa/Lagos, Asia/Dhaka or Europe/London. In Winbox it is System → Clock, where you pick it from a list. NTP always delivers universal time; the time zone turns it into your local time.

2a. NTP client on RouterOS v7

/system ntp client set enabled=yes servers=time.cloudflare.com,pool.ntp.org
/system ntp client print

After a short while the status reads synchronized.

2b. NTP client on RouterOS v6

By server name:

/system ntp client set enabled=yes server-dns-names=time.cloudflare.com,pool.ntp.org
/system ntp client print

Or by address:

/system ntp client set enabled=yes primary-ntp=162.159.200.1 secondary-ntp=162.159.200.123

Server names need working DNS on the router; see DNS setup. Addresses work without DNS but stop working if the provider ever changes them.

The built-in fallback

RouterOS can also take the time from MikroTik's own cloud service when no NTP client is enabled. It is on by default on most devices:

/ip cloud set update-time=yes
/ip cloud print

It is less exact than NTP but enough for dates and schedules.

Set the time by hand

Only useful when the router has no internet at all. It is lost again at the next power cut:

/system clock set time=14:30:00

Set the date in Winbox under System → Clock; the date is written differently on v6 and on newer v7 versions.

Why the clock matters

  • Hotspot and PPPoE expiry. Scripts that expire users compare a stored date with the router's clock. A router that boots in the past keeps expired users online; one that jumps forward cuts off paying customers. See how hotspot user expiry works.
  • Schedulers. A nightly backup or reboot set for 03:00 runs at the wrong hour, or not on the day you expect. See scheduler and scripts.
  • Logs. Entries with a wrong date are useless when you need to know when a line dropped.
  • Certificates. Every certificate is valid between two dates. With a clock in the past, secure connections made by the router fail because the certificate looks "not yet valid".
  • Time-based firewall rules and queues switch on and off at the wrong hours.

If it does not synchronise

  • No internet yet at boot: normal. The client keeps trying and catches up when the line is up.
  • Names do not resolve: the router has no DNS servers. Test with :put [:resolve pool.ntp.org].
  • The firewall blocks the replies: the input chain must accept established and related connections, as in the basic firewall.
  • The ISP blocks NTP (UDP port 123): rare, but it happens. Leave /ip cloud update-time on as the fallback.

Where RadiusNest fits

With RadiusNest the end date of each customer is kept centrally and checked at login, so a router that boots with the wrong date does not expire anyone early or late. The clock still matters for your own schedulers and logs, which is why the RadiusNest router setup script turns on time sync when the router has none.

Start the free trial See pricing

Questions and answers

Why does my MikroTik lose the time after a power cut?

Most models have no clock battery. They start from the last saved time and need NTP or the cloud time service to correct it after each boot.

The date is right but the hour is wrong. Why?

The time zone is not set. Choose your region in System, Clock; the NTP client only supplies universal time.

Which NTP server should I use?

Any public one works, for example time.cloudflare.com or pool.ntp.org. Set two names so one can fail.

Related guides

Start the free trial See pricing