That's a fantastic idea! I will add it. I ended up migrating it off Cloudron for the time being because I have come to depend on UK for work and all the notifications were bogging me down.

I will restart the old instance to test and will report back what I find out.

Sorry will test this afternoon. Was at an little holiday 😅

This sounds like you are not running Uptime Kuma on Cloudron but on Synology. This is a forum for topics around Cloudron and the apps intalled on Cloudron. You may have to reach out to Synology forums or support.

@arshsahzad Uptime Kuma cannot monitor GIT SSH which is behind Cloudflare. The service is not reachable when Cloudflare proxying is enabled . You can test this yourself, try to git ssh clone when proxying is enabled - it won't work.

@hcj-online can you check if you have enough disk space? Uptime kuma only uses sqlite even.

@jdaviescoates said in How to setup email notifications?:

@hcj-online I've not tried this yet,

Just tested it, and yep, that works.

Note: Hostname = your Outgoing Mail (SMTP) server address (which will be your my. domain unless you've changed it in the settings at the bottom of Email settings at https://my.yourdomain.coop/#/email)

I put 587 for port and left the security as None / STARTTLS

7fb6fe6d-9663-4caf-b2ac-01e81fade89a-image.png

Also, when I tried using e.g. {{STATUS}} etc in the Custom Subject settings it didn't actually work, I just got subjects like this coming through:

f7226dc4-21c8-495c-99b7-1beba6d6d32e-image.png

So I recommend leaving that blank to keep the defaults.

@jdaviescoates that worked !
Thank you

@girish done https://forum.cloudron.io/topic/8487/enhance-app-proxy-app-with-path-and-port-support

BTW, if you end up opening upstream for TCPS, you should also tell them to add STARTTLS as an option.

openssl s_client -connect mail.domaincom:25 -showcerts -starttls smtp will help test the cert of a mail server for protocols like sieve, smtp that use starttls.

Good suggestions, I have fixed up the package.

@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.