uptime-kuma
uptime-kuma copied to clipboard
Monitor showing offline but its online
⚠️ Please verify that this bug has NOT been raised before.
- [X] I checked and didn't find similar issue
🛡️ Security Policy
- [X] I agree to have read this project Security Policy
📝 Describe your problem
I have the problem, that all of my monitors except 1 showing as offline. i can reach the website normally. Can someone help me by that?
One Monitor showing "error request aborted"
The other two showing "timeout of 48000ms exceeded"
🐻 Uptime-Kuma Version
1.16.1
💻 Operating System and Arch
Debian 10 x86_64
🌐 Browser
Microsoft Edge 103.0.1264.37
🐋 Docker Version
20.10.17
🟩 NodeJS Version
No response
Check if you can ping it directly from your server via ssh
You mean with the ping command? if yes, yes. i can ping every server
I got the same exact problem every morning at 5-6 AM for an hour. It says that it's down, but it's not. With the same error "timeout of 48000ms exceeded". Usually there are 2 websites, but it happens to be only 1 or 3 sometimes. I've increased the Heartbeat Interval and Retries, but no luck. Anyone can help?
I got the same exact problem every morning at 5-6 AM for an hour. It says that it's down, but it's not. With the same error "timeout of 48000ms exceeded". Usually there are 2 websites, but it happens to be only 1 or 3 sometimes. I've increased the Heartbeat Interval and Retries, but no luck. Anyone can help?
We got the same thing last night for maybe 40-50 Websites.
With me it is not only over night but permanent.
Now my Discord-Webhook showing sometimes, that the Services are online but then it says there are offline.
Same issue here, see: https://github.com/louislam/uptime-kuma/issues/1621
Same issue here, suddenly we are getting "timeout of 48000ms exceeded" on most of the checks.
Anyone has any clue?
Same issue here, suddenly we are getting "timeout of 48000ms exceeded" on most of the checks.
Anyone has any clue?
This may help: https://github.com/louislam/uptime-kuma/wiki/Troubleshooting
Hi I have tried to run the cmd without apparently any issue.
Best regards,
Francesco.
@.*** ~]$ curl https://google.com
301 Moved
The document has moved here.@.*** ~]$ ping google.com PING google.com (172.217.168.206) 56(84) bytes of data. 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=1 ttl=53 time=2.77 ms 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=2 ttl=53 time=2.52 ms 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=3 ttl=53 time=2.80 ms 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=4 ttl=53 time=2.36 ms 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=5 ttl=53 time=2.36 ms 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=6 ttl=53 time=2.42 ms 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=7 ttl=53 time=2.63 ms 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=8 ttl=53 time=2.67 ms 64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=9 ttl=53 time=2.33 ms ^C
On 2 Aug 2022, at 12:18, Louis Lam @.***> wrote:
Same issue here, suddenly we are getting "timeout of 48000ms exceeded" on most of the checks.
Anyone has any clue?
This may help: https://github.com/louislam/uptime-kuma/wiki/Troubleshooting https://github.com/louislam/uptime-kuma/wiki/Troubleshooting — Reply to this email directly, view it on GitHub https://github.com/louislam/uptime-kuma/issues/1848#issuecomment-1202295726, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFCDTMMWIQ2MPJZW2KPTRX3VXDYYDANCNFSM52CMU2PA. You are receiving this because you commented.
Yeah, that works for me as well. It's really that Uptime Kuma gets bogged down, and it happens more frequently when the container is running for a longer period of time. I've not found anything useful in the logs either, it just times out.
30s monitor (both monitors have the same settings and site, except for the interval):
1m monitor:
Same issue here. When I try to ping the url from within the docker container, as suggested here, I also do get a timeout.
BUT... the same website can be reached and pinged from other systems AND I can still ping other monitored websites from within the Uptime Kuma docker container, so it's not a general networking issue with the container / server / hosting.
So it seems something is getting bogged down in Uptime Kuma itself.
Note Most of our monitored websites are behind Cloudflare, but some are not. And until now I only experienced the issue with websites that are not behind Cloudflare. Though not all those "non-cloudflare" websites are affected at the same time. At the moment 2 of the non-cloudflare websites are affected, but several weeks ago we had the same issue with one of those 2 websites (and another one), but not the other.
We also see different errors prior to the timeout issues:
140059089770432:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/ssl3_record.c:677
and
getaddrinfo EAI_AGAIN <hostname>
Same issue here. When I try to ping the url from within the docker container, as suggested here, I also do get a timeout.
BUT... the same website can be reached and pinged from other systems AND I can still ping other monitored websites from within the Uptime Kuma docker container, so it's not a general networking issue with the container / server / hosting.
So it seems something is getting bogged down in Uptime Kuma itself.
Note Most of our monitored websites are behind Cloudflare, but some are not. And until now I only experienced the issue with websites that are not behind Cloudflare. Though not all those "non-cloudflare" websites are affected at the same time. At the moment 2 of the non-cloudflare websites are affected, but several weeks ago we had the same issue with one of those 2 websites (and another one), but not the other.
We also see different errors prior to the timeout issues:
140059089770432:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/ssl3_record.c:677
and
getaddrinfo EAI_AGAIN <hostname>
Hey, we "fixed" that issue by simply not using docker. But sometimes we are still getting the timeout error but not as often as using docker.
@d-delaey thanks for the suggestion, but we're running Uptime Kuma as part of a dockerized environment, so not using docker is not an option for us in this case.
We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.
Please don't close this issue as it is still not fixed!
Same issue here. When I try to ping the url from within the docker container, as suggested here, I also do get a timeout.
BUT... the same website can be reached and pinged from other systems AND I can still ping other monitored websites from within the Uptime Kuma docker container, so it's not a general networking issue with the container / server / hosting.
So it seems something is getting bogged down in Uptime Kuma itself.
Note Most of our monitored websites are behind Cloudflare, but some are not. And until now I only experienced the issue with websites that are not behind Cloudflare. Though not all those "non-cloudflare" websites are affected at the same time. At the moment 2 of the non-cloudflare websites are affected, but several weeks ago we had the same issue with one of those 2 websites (and another one), but not the other.
We also see different errors prior to the timeout issues:
140059089770432:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/ssl3_record.c:677
and
getaddrinfo EAI_AGAIN <hostname>
Make sure you are not using Alpine based image.
For SSL error, please double check http://
vs https://
Same issue here. When I try to ping the url from within the docker container, as suggested here, I also do get a timeout. BUT... the same website can be reached and pinged from other systems AND I can still ping other monitored websites from within the Uptime Kuma docker container, so it's not a general networking issue with the container / server / hosting. So it seems something is getting bogged down in Uptime Kuma itself. Note Most of our monitored websites are behind Cloudflare, but some are not. And until now I only experienced the issue with websites that are not behind Cloudflare. Though not all those "non-cloudflare" websites are affected at the same time. At the moment 2 of the non-cloudflare websites are affected, but several weeks ago we had the same issue with one of those 2 websites (and another one), but not the other. We also see different errors prior to the timeout issues:
140059089770432:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/ssl3_record.c:677
andgetaddrinfo EAI_AGAIN <hostname>
Make sure you are not using Alpine based image.
I'm not since I'm running Uptime Kuma with Cloudron, which uses Ubuntu based docker images
For SSL error, please double check
http://
vshttps://
All sites in Uptime Kuma are configured with https, so there shoudn't be any reason for Uptime Kuma trying to access the sites over http.
For me still happening
For me still happening
Yes it still happening to me aswell
Getting this error when trying to send a webhook, as in https://github.com/louislam/uptime-kuma/issues/1697, running via pm2
Start to happen to me after update the docker image.
Same issue here, suddenly we are getting "timeout of 48000ms exceeded" on most of the checks. Anyone has any clue?
This may help: https://github.com/louislam/uptime-kuma/wiki/Troubleshooting
No curl installed in docker
After stop docker, pull new image and start docker.
ping and curl working from inside the container, nothing is working from this.
same here using the latest image. https://github.com/louislam/uptime-kuma/wiki/Troubleshooting using the troubleshooting guide above, the container was able to curl and ping the urls, however, the urls still appear as down in kuma
I have the same issue for months.. At first I thought this issue from my VPS provider, but after I had big fights with multiple VPS providers, I found out it's only happening from Uptime Kuma.
I think I'll just look for another tool and apologize to the VPS providers!