By turning off the «Allow Access to this Dashboard via Remote / Cloud Links» option, does that stop communication to the cloud all together?
You find this under advanced options on each dashboard created.
By the way, do you have a longer history in Grafana( I guess that’s you logger graph here) that maybe shows this happening for previous updates? The latest 2.1.9.115 came out quite fast after 2.1.9.114. Would be cool if you did. 
That might explain why you do not experience slowdowns? Maybe more stable or without new code that might be the culprit? Who knows...
First figure here shows the last two update on the 21st.
However looking at that I saw similar stuff on the 15th, so I went further back and saw stuff on the 8th and 1st... so a weekly problem. Some of these I noticed personally, but I've also been out of town, so who knows.
I think this means that starting in February I have had some issue that is weekly recurring, popping up on Saturdays, and it was coincidence that it happened this week and last with updates being released.
I went further back and prior to February this weekly issue dissappears (so I need to find what changed there) But going back to the last two updates I see that the issue does occur here on January 9th.
And here in December. Worth noting here, there were updates on basically the 10th, 11th, 12th and 13th, but only the one on the 13th caused issue?
Prior to December 11th I observed the same behavior of slow downs when updates became available, but was not logging at that time.
1 Like
How do you do this exactly? Because if you are just calling the http time to load the devices page I can easily explain why you experience this.
Btw, I too have a suspicion that the update notification can impact response time of the hub, but haven't noticed it with all updates. Only two times, and the last three updates I didn't anymore. So I expected they've solved it. There is another topic or metion about this from a couple of month ago if I remember correctly.
Edit: found it Slow Hub when there is an update available
2 Likes
It's the http time. Node-RED Flow - Hubitat Performance Monitor
I'm interested to hear why it happens.
I know that using this http time is not a direct correlation with actual hub performance (I get warnings sometimes that my hub response time is too long but notice no performance issues). However, when I am talking about these issues with updates, I am not just referencing my logs, but also my experience at that time.
1 Like
The problem is that as soon as there is an update all admin pages get that red notification on top. To load that it has to do some cloud calls to see how many updates are ready for you, that takes time. In case of no updates the call to the cloud takes less time and no notification is shown.
So to have a correct measure of possible slowness you could test for http first byte, or with @bptworld hub watchdog. [RELEASE] Hub Watchdog - Simple way to monitor if your hub is slowing down or not
I haven’t measured my hub response time, but I feel like I have the exact same experience.
Whenever some of my routines don’t run smoothly, I do the same and check for updates - usually there is one
Last night this showed in the form of a few lights not turning off correctly as we ran the good night routine..
So does it only check for what number to display once it has checked to see if it should display any number at all? Otherwise I would think it would always slow things down checking to see if there was a notification to show.
Also I don't think that alone will cause the average page load time to go from being too short to really measure to then being 5 plus seconds. I know it isn't a fully accurate way to measure, which makes the data quantitatively innaccurate, but does not reduce the gualitative utility of the data. I agree first byte might be more accurate, but it also might be stuck in the noise floor most of the time. Measuring the whole load time has proven good enough to show trends, that mostly agree with observed performance of the hub.
Also, the only reason I started logging this was because of observed slow downs in hub performance. I honestly don't really look at the warning about response time unless I notice actual problems with the hub, or I am out of town (sometimes a reboot will get things back to normal so I don't hear about it from the family when I get home).
Yep, before I logged this I would notice that a goodnight routine would miss a light or something like that (or the front door, which I will harp on again, because that is very annoying). When that happened I would pull up the web UI and sure enough, an update is available.
I have the same issue and support didn’t find anything wrong. As soon as I applied the update I would be fine.
What happens if you block access to the Hubitat servers. Does your hub perform slow?
I’ll try the next time
Just to throw in my 2 cents. I had that little red flag on my hub for a year since July of 2019. I just upgraded to the latest a day ago. It doesn't seem any different. 
Next time up here:
New Version Available: 2.1.9.117 is out now.
Did not get a message in the browser though, this time. Had to manually trigger the check. Updating now. 
Changelog:
I'm not sure where you got the idea that this is how it works, did someone tell you this?
There is a process that runs every 24 hours in the background that calls the Hubitat servers, the message is approximately 100 bytes long and is json (it includes the current version you are running and your hub id). The server will respond with an empty json object if there is no update, or it will return a version number if there is one available. The version number is then stored in memory, that is how you get the little icon in the corner. This call also runs at startup (again, in the background) so if you reboot you'll see the message sooner than your normal 24 hour call.
12 Likes
It was an assumption. Apparently a bad one. But the reason why I made it is because it sometimes takes about 2-3 seconds after the whole page is loaded till the red notification appears. So the process, albeit totally local, does something what takes a lot of time now and then. That shouldn't happen if it's only 100bytes I think. Or am I wrong in this one too?
Besides that it doesn't really matter how it's done, the fact remains that it clearly messes with the total load time of the http call. And the point I was trying to make is that the http call isn't the best way to measure overall hub slowness.
That's the point of my post, there is never a call to our servers to check for an update when the page is loaded, it's already been done in the background.
2 Likes
Then we're back to the OP. Because if it's not the extra http load time, it must be something else and it still looks like it's related to the update.
I assure you it is not caused by the check for an update or an update being available.
I think what is happening here is an illusory correlation.
6 Likes
1 Like
