Daily Maintenance - What Time?

@support_team - Is there any time to determine exactly what time the nightly maintenance takes place? Something is occurring at around 2 AM that is causing latency/packet loss on my Unifi UDR and it's disconnecting the internet connection. This happened over the last few days:

27th - packet loss reported at 2.06 AM with disconnection/restoral message at 2.08 AM.
26th - packet loss 2.05 AM
25th - restoral message at 2.19 AM.

For today I get a bit more detail (not sure why the Unifi internet logs in the dashboard only show the current day)

The C8 is running Is there any issue with disconnecting the hub from the internet to prove it's something else going on at this time? Thanks.

Personally I would update to tge latest hub software and see if the issue persists.
If it does, take it from there.

1 Like

That's what I was wondering, whether that related to the regular maintenance as well as the backup....

Believe the default is 0200, I moved mine to make sure the hub wasn't busy doing other things until after my wife's normal routine places her in bed. :sunglasses:

1 Like

Me too.... Oh... No, I don't mean.... :slight_smile:


I'm not sure how the hub would influence the WAN connectivity check from the UDR. What has you thinking the hub is the cause?

1 Like

Only time the hub activity should have an impact in this scenario would be during a cloud backup.

Still seems a little extreme to be impacting the general WAN connection....? Still feels (to me) like something else is going on outside of HE.... That said, I can understand @johnwill1 's desire to at least rule out HE from being the root cause, but my money would be on something else impacting the Internet connection.



IIRC right, the UDR has it's own tests that it runs for checking WAN connectivity which would generate those alerts. Pretty sure they test against Google.com, Facebook.com, and Twitter.com for that.

I missed that. I didn't realise it was under backup/restore. Mine is set to 2:15 AM.

I've been reluctant to do that due to the zigbee issues and other things users have been reporting. I generally install every update and the hub is registered for beta releases but I've been a little more cautious of late.

I'm not looking to blame the hub, just trying to exclude things as I've nothing going on at that time that I can think of.

Understood. I don't have hub protect so wouldn't have a cloud backup taking place.


Yes by default the UDR pings ubnt.com. I've also got a Think Broadband monitor set to ping the connection.

It started out that the UDR was randomly reporting high latency and packet loss. At some point/threshold the UDR decides to disconnect/reconnect itself from the WAN (which is truly annoying as there seems no way to disable that function).

Sometimes I see events logged in the UDR that correspond with the times of errors in the cable modem network logs (Virgin Media Hub 3.0) which would indicate an issue on the ISP side. However at other times nothing is logged in the modem (which points [possibly]to a UDR issue). Ubiquiti support have had the support file from the UDR, can see the packet loss and latency and have provided a few things to try (adjust ARP cache timeout, put a gigabit switch between the modem and UDR (to rule out some negotiation compatibility). So far nothing has worked so it's niggling me.

I checked my logs and I'm actually seeing some of the same errors, but they don't correlate back to the hub. What Unifi OS and Network versions are you running? I didn't start seeing the "packet loss" error until I took the Unifi OS 2.5.X upgrade and Network to 7.3.83. I'm wondering if something with the WAN test logic changed.

1 Like

There are a few people reporting it on the unifi forums. I'm on UDR 3.0.17 and network 7.3.83.

I think I may have two completely separate issues and I'm incorrectly linking them:

1 - Some occasional/random sync failures on my line which result in everything going down and that also gets logged by the UDR.

2 - Some over zealous latency/packet loss reporting by the UDR that decides to drop the WAN and reconnect in an attempt to rectify that (when it should just leave it alone)


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.