@matbrgz I think that ends up protected all of uptime kuma and not just the status page . But of course, one can always tinker the configs in such a way that only specific pages are protected (one has to also investigate protecting API requests to the backend etc). I think this has to be implemented in uptime kuma itself to be fixed reliably.

OK, the mystery remains then. Nothing has changed on our side to cause this issue as such .

Okay my bad. The last time I did this was for a Wordpress which used Apache. You can also do basic auth with NGINX but the configuration for app packages is read only (as far as I remember). @girish said in Uptime Kuma - Securing Status Pages: Oh, does that password make the status pages protected too? I assumed that because the Dashboard was not reachable without logging in but sadly it is not the case. I think there is no easy way for us to fix that and it will remain an upstream issue.

@girish It works! Thank you.

Thank you for the suggestion. We are not noticing issues wit Rocket.chat, so the issue might be with Uptime Kuma or its database.

@Lonkle Yes please, if you can put your fork and notes somewhere, I can look into incorporating it accordingly.

@girish not sure about 0 size ever, but I don't think so. Anyway, after deleting some new .bak files from /app/data/data, Cloudron System Info now reporting a more reasonable 455Mb size for the deployed app. Will try and keep an eye on it. May export, uninstall, reinstall, import. Although I think I did that once before. Clearing all stats and shrinking database gives a 1.5Mb size.

@humptydumpty to reliably update i ended up always updating the docker tag to the desired version. With the tag updated you just need to run flyctl deploy again.

I moved this to a separate topic.

@JLX89 maybe you want to add a retry to this. So that it's only marked as down at the e.g. second failed check.

@JLX89 have you also made sure, the the existing uptime app has been updated to the latest version with .1 instead of.0? For me it then immediately worked. What was a bit strange is that there is no validation for configured domains in Kuma. You simply enter it as it's domain in the dashboard and then it will be served through it. I have now my Kuma reachable from uptime.domain and the public status page at status.domain.

@girish thanks it has been resolved

@luckow for reference, this is the Expression I have in my 'text' field: {{JSON.stringify($json["body"])}} I output the entire JSON body stringified because I use this webhook for multiple incoming notifications and they contain different payloads. But you can try and extrapolate from here by bringing in just the fields you need, i.e msg, monitor, etc.