Wanted to share a working solution, lightly adapted for Cloudron from Github issue comment referenced above: Enter Recovery Mode On the app's terminal: bash sqlite3 /app/code/data/kuma.db "DELETE FROM setting WHERE key = 'migrateAggregateTableState';" Exit Recovery Mode

Took a little peek into the MariaDB/MySQL support of Uptime Kuma https://github.com/louislam/uptime-kuma/wiki/Environment-Variables#mariadb-environment-variables Unfortunately the official statement is that migrating an existing SQLite database to MariaDB is not supported. But, there is a way and someone did the work already https://github.com/louislam/uptime-kuma/issues/5280#issuecomment-2642224548 How stable this approach is needs to be verified.

@Lanhild You should really consider switching to https://github.com/zabbix/zabbix (Number of monitors: 170)

@jdaviescoates said in Regular short getaddrinfo EAI_AGAIN outages: I recently enabled email notifications on my Uptime Kuma and I've noticed there are regular short outages. Something to do with getaddrinfo EAI_AGAIN [image: 1678353141627-screenshot-from-2023-03-09-09-08-30-resized.png] Any idea what's causing this and how to resolve it? Apparently EAI_AGAIN is a DNS lookup timed out error, means it is a network connectivity error or proxy related error. According to https://stackoverflow.com/questions/40182121/whats-the-cause-of-the-error-getaddrinfo-eai-again Oh, and here it says: EAI_AGAIN means the DNS server replied that it cannot currently fulfill the request. (If you want the hairy details, the RCODE field in the response is set to 2, SERVFAIL.) There is no single solution because it entirely depends on why the DNS server sends that back. Maybe it's overloaded, maybe the network is down, maybe it got the same reply from its upstream server. Learn more In general, the best you can do is wait a while and try again. Hope that helps. I wonder what the specific issue is in my case (perhaps just network issues with Netcup?) Same thoughts. I t has been addressed in the beautiful manner.

@joseph That's the plan for the future. Now I'm interested in getting the max number of monitored instances. 62 is way too many. 180 days retention policy for the metrics ditto. Sqlite DB is about 2 GB in size. Purging old data in the database does not work. Let's see.

Looks like it's solved! Thanks @vladimir.d (https://git.cloudron.io/packages/uptime-kuma-app/-/commit/42c2f7a6d689ab08a1c05317fede770e8d72d6f0)

https://docs.cloudron.io/apps/uptime-kuma/#reset-password

These appear to be V1 limitations and V2 is dropping soon. Until then, reduce/archive data, increase time between checks or cleanup number of checks for V1.

Oh wow, lots of changes! Let us know if you need anything.

This is fixed with Cloudron 8. If all update attempts fail due to the backup for uptime kuma failing, you can stop the app for the update first.

Makes sense. Thanks for the insight, I'll close the PR as it's not relevant right now.

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.