You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once a day, as per our FAQ, but this does sound similar to another case where only some sites observatory rating didn't get updated while other sites were: #31 (comment)
I'll investigate, try restarting the service, if necessary, and report back here. I wonder where this is being cached?
For future record, at this time the directory shows the instance having a B rating, while on the observatory the result is A+ (score of 105 of 100).
took a snapshot of ratings before doing anything: SELECT url, scans.rating, scans.percent FROM instances JOIN scans ON instances.id = scans.instance_id ORDER BY url; - confirmed that the rating was stored as B / 83
confirmed that the cronjobs do run daily, output gets logged, last update of a observatory rating found on September 17th
manually queried the instance from the VM the directory runs on (outside of the container image, the container doesn't contain a shell or CLI tools): wget https://http-observatory.security.mozilla.org/api/v1/analyze?host=paste.devsite.pl -> got the expected A+ / 105 score returned
ran the cronjob manually, ran in 20s
re-ran the SQL query, compared the diff -> 4 instances got updated ratings
A restart of the service wasn't necessary - the cronjobs launch independent instances of the same binary, so there should not be any caches shared with the service. The one thing out of the order is that I ran the job at a different time than usual and that I ran the wget before I triggered the cronjob. It might be some kind of rate limiting of Mozilla's CDN? I'll have to keep an eye on this.
I'm asking because I've improved the score of my instance (https://paste.devsite.pl/), but on the Instance Directory page it's still the old value.
The text was updated successfully, but these errors were encountered: