starred/uptime-kuma
1
0
Fork 0
mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00
Code Issues 754 Projects Packages Wiki Activity

monitor type ping stopped working #177

New issue
Closed
opened 2026-02-28 01:37:38 -05:00 by deekerman · 18 comments
deekerman commented 2026-02-28 01:37:38 -05:00
Owner
Copy link

Originally created by @ovizii on GitHub (Aug 31, 2021).

Info
Uptime Kuma Version: 1.3.2
Using Docker?: Yes
OS: Windows (client) Docker with uptime-kuma runs on Debian 10
Browser: Chrome

I installed uptime-kuma a few days ago and setup a few monitors, most of them https and one as ping type. The ping type one stopped working yesterday evening. I know the target is up, even if I do a docker exec -ti uptime-kuma sh and do a manual ping to the same target the ping works so why does it keep failing for a full 24h inside uptime-kuma?

Also, uptimerobot reports no issues pinging this particular host.

Open for any suggestions.

Originally created by @ovizii on GitHub (Aug 31, 2021). **Info** Uptime Kuma Version: 1.3.2 Using Docker?: Yes OS: Windows (client) Docker with uptime-kuma runs on Debian 10 Browser: Chrome I installed uptime-kuma a few days ago and setup a few monitors, most of them https and one as ping type. The ping type one stopped working yesterday evening. I know the target is up, even if I do a `docker exec -ti uptime-kuma sh ` and do a manual ping to the same target the ping works so why does it keep failing for a full 24h inside uptime-kuma? Also, uptimerobot reports no issues pinging this particular host. Open for any suggestions.
deekerman 2026-02-28 01:37:38 -05:00
  • closed this issue
  • added the
    help
         label
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@louislam commented on GitHub (Aug 31, 2021):

Are there any error? You can over the bar, check docker log or event list

image

@louislam commented on GitHub (Aug 31, 2021): Are there any error? You can over the bar, check docker log or event list ![image](https://user-images.githubusercontent.com/1336778/131507783-dad4d028-bb2b-4049-ac38-540eafae5fa8.png)
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@ovizii commented on GitHub (Aug 31, 2021):

Every single ping fails since yesterday. docker-compose down followed by docker-compose pull and docker.compose up -d does not show any errors or changes besides the failed ping.

Not sure if it will help but here you go:

docker-compose  logs -f
uptime-kuma | Monitor #6 'MzansiRace': Successful Response: 9245 ms | Interval: 60 seconds | Type: http
uptime-kuma | Monitor #19 'PBS External': Failing: PING ict.zfs.rent (63.81.90.219): 56 data bytes
uptime-kuma |
uptime-kuma | --- ict.zfs.rent ping statistics ---
uptime-kuma | 1 packets transmitted, 0 packets received, 100% packet loss
uptime-kuma |  | Type: ping
uptime-kuma | Monitor #7 'pacura.ru': Successful Response: 12581 ms | Interval: 60 seconds | Type: http

I've shortened the logs output but as you can see, the ping is failing.

docker exec -ti uptime-kuma sh
 ping ict.zfs.rent
PING ict.zfs.rent (63.81.90.219): 56 data bytes
64 bytes from 63.81.90.219: seq=0 ttl=57 time=171.232 ms
64 bytes from 63.81.90.219: seq=1 ttl=57 time=171.437 ms
64 bytes from 63.81.90.219: seq=2 ttl=57 time=171.664 ms
^C
--- ict.zfs.rent ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 171.232/171.444/171.664 ms

from my docker host:

ping ict.zfs.rent
PING ict.zfs.rent (63.81.90.219) 56(84) bytes of data.
64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=1 ttl=58 time=171 ms
64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=2 ttl=58 time=171 ms
64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=3 ttl=58 time=171 ms
64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=4 ttl=58 time=171 ms
^C
--- ict.zfs.rent ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 8ms
rtt min/avg/max/mdev = 171.257/171.322/171.406/0.418 ms

image

image

@ovizii commented on GitHub (Aug 31, 2021): Every single ping fails since yesterday. docker-compose down followed by docker-compose pull and docker.compose up -d does not show any errors or changes besides the failed ping. Not sure if it will help but here you go: ``` docker-compose logs -f uptime-kuma | Monitor #6 'MzansiRace': Successful Response: 9245 ms | Interval: 60 seconds | Type: http uptime-kuma | Monitor #19 'PBS External': Failing: PING ict.zfs.rent (63.81.90.219): 56 data bytes uptime-kuma | uptime-kuma | --- ict.zfs.rent ping statistics --- uptime-kuma | 1 packets transmitted, 0 packets received, 100% packet loss uptime-kuma | | Type: ping uptime-kuma | Monitor #7 'pacura.ru': Successful Response: 12581 ms | Interval: 60 seconds | Type: http ``` I've shortened the logs output but as you can see, the ping is failing. ``` docker exec -ti uptime-kuma sh ping ict.zfs.rent PING ict.zfs.rent (63.81.90.219): 56 data bytes 64 bytes from 63.81.90.219: seq=0 ttl=57 time=171.232 ms 64 bytes from 63.81.90.219: seq=1 ttl=57 time=171.437 ms 64 bytes from 63.81.90.219: seq=2 ttl=57 time=171.664 ms ^C --- ict.zfs.rent ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 171.232/171.444/171.664 ms ``` from my docker host: ``` ping ict.zfs.rent PING ict.zfs.rent (63.81.90.219) 56(84) bytes of data. 64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=1 ttl=58 time=171 ms 64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=2 ttl=58 time=171 ms 64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=3 ttl=58 time=171 ms 64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=4 ttl=58 time=171 ms ^C --- ict.zfs.rent ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 8ms rtt min/avg/max/mdev = 171.257/171.322/171.406/0.418 ms ``` ![image](https://user-images.githubusercontent.com/837902/131509211-86d9fd4e-9946-46cb-b2c6-69f5eb92a467.png) ![image](https://user-images.githubusercontent.com/837902/131509288-41456822-7a85-4405-ba45-3b7659d70e49.png)
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@louislam commented on GitHub (Aug 31, 2021):

Really strange, as Uptime-kuma is also using the builtin "ping"

Could you also try this? This is how Uptime Kuma executes the ping command

ping -n -w 2 -c 1 ict.zfs.rent
@louislam commented on GitHub (Aug 31, 2021): Really strange, as Uptime-kuma is also using the builtin "ping" Could you also try this? This is how Uptime Kuma executes the ping command ```bash ping -n -w 2 -c 1 ict.zfs.rent ```
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@ovizii commented on GitHub (Aug 31, 2021):

Really strange, as Uptime-kuma is also using the builtin "ping"

Could you also try this? This is how Uptime Kuma executes the ping command

ping -n -w 2 -c 1 ict.zfs.rent

That does indeed fail. Need to check the manual what all those switches for the ping command do.

docker exec -ti uptime-kuma sh
/app # ping -n -w 2 -c 1 ict.zfs.rent
PING ict.zfs.rent (63.81.90.219): 56 data bytes

--- ict.zfs.rent ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
@ovizii commented on GitHub (Aug 31, 2021): > Really strange, as Uptime-kuma is also using the builtin "ping" > > Could you also try this? This is how Uptime Kuma executes the ping command > > ```shell > ping -n -w 2 -c 1 ict.zfs.rent > ``` That does indeed fail. Need to check the manual what all those switches for the ping command do. ``` docker exec -ti uptime-kuma sh /app # ping -n -w 2 -c 1 ict.zfs.rent PING ict.zfs.rent (63.81.90.219): 56 data bytes --- ict.zfs.rent ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss ```
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@ovizii commented on GitHub (Aug 31, 2021):

from inside your container, the '-n' option seems unknown.

ping -h
ping: unrecognized option: h
BusyBox v1.31.1 () multi-call binary.

Usage: ping [OPTIONS] HOST

Send ICMP ECHO_REQUEST packets to network hosts

        -4,-6           Force IP or IPv6 name resolution
        -c CNT          Send only CNT pings
        -s SIZE         Send SIZE data bytes in packets (default 56)
        -i SECS         Interval
        -A              Ping as soon as reply is recevied
        -t TTL          Set TTL
        -I IFACE/IP     Source interface or IP address
        -W SEC          Seconds to wait for the first response (default 10)
                        (after all -c CNT packets are sent)
        -w SEC          Seconds until ping exits (default:infinite)
                        (can exit earlier with -c CNT)
        -q              Quiet, only display output at start
                        and when finished
        -p HEXBYTE      Pattern to use for payload

I upped the seconds to wait to 5 and the ping works all of a sudden:

ping -w 5 -c 1 ict.zfs.rent
PING ict.zfs.rent (63.81.90.219): 56 data bytes
64 bytes from 63.81.90.219: seq=0 ttl=57 time=172.820 ms

--- ict.zfs.rent ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 172.820/172.820/172.820 ms

Might be internet problems at home where this NAS runs? I'm currently travelling so can'T physically check but I can access my services at home just fine.

@ovizii commented on GitHub (Aug 31, 2021): from inside your container, the '-n' option seems unknown. ``` ping -h ping: unrecognized option: h BusyBox v1.31.1 () multi-call binary. Usage: ping [OPTIONS] HOST Send ICMP ECHO_REQUEST packets to network hosts -4,-6 Force IP or IPv6 name resolution -c CNT Send only CNT pings -s SIZE Send SIZE data bytes in packets (default 56) -i SECS Interval -A Ping as soon as reply is recevied -t TTL Set TTL -I IFACE/IP Source interface or IP address -W SEC Seconds to wait for the first response (default 10) (after all -c CNT packets are sent) -w SEC Seconds until ping exits (default:infinite) (can exit earlier with -c CNT) -q Quiet, only display output at start and when finished -p HEXBYTE Pattern to use for payload ``` I upped the seconds to wait to 5 and the ping works all of a sudden: ``` ping -w 5 -c 1 ict.zfs.rent PING ict.zfs.rent (63.81.90.219): 56 data bytes 64 bytes from 63.81.90.219: seq=0 ttl=57 time=172.820 ms --- ict.zfs.rent ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 172.820/172.820/172.820 ms ``` Might be internet problems at home where this NAS runs? I'm currently travelling so can'T physically check but I can access my services at home just fine.
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@louislam commented on GitHub (Aug 31, 2021):

Still a bit strange as your response time is within 2 seconds.

@louislam commented on GitHub (Aug 31, 2021): Still a bit strange as your response time is within 2 seconds.
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@louislam commented on GitHub (Aug 31, 2021):

My guess: Your dns server is slow. It takes more than 2 seconds to resolve a domain.

You can ping the IP directly.

@louislam commented on GitHub (Aug 31, 2021): My guess: Your dns server is slow. It takes more than 2 seconds to resolve a domain. You can ping the IP directly.
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@chakflying commented on GitHub (Aug 31, 2021):

@louislam Seems like DNS is still a huge problem. Looking around curiously I found that many people reported having DNS issues on Alpine with Docker, and some reported issues fixed by switching to Debian or other OS. Might be worth switching to Debian despite the larger image size.

@chakflying commented on GitHub (Aug 31, 2021): @louislam Seems like DNS is still a huge problem. Looking around curiously I found that many people reported having DNS issues on [Alpine with Docker](https://github.com/gliderlabs/docker-alpine/issues/255), and some reported issues fixed by switching to Debian or other OS. Might be worth switching to Debian despite the larger image size.
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@louislam commented on GitHub (Aug 31, 2021):

@louislam Seems like DNS is still a huge problem. Looking around curiously I found that many people reported having DNS issues on Alpine with Docker, and some reported issues fixed by switching to Debian or other OS. Might be worth switching to Debian despite the larger image size.

Omg, that is surprising me...

@ovizii Could you please help me try again the command in your host machine? Thank you.

ping -n -w 2 -c 1 ict.zfs.rent

If your host machine is working, than I believe that Alpine Docker is having a huge problem.

@louislam commented on GitHub (Aug 31, 2021): > @louislam Seems like DNS is still a huge problem. Looking around curiously I found that many people reported having DNS issues on [Alpine with Docker](https://github.com/gliderlabs/docker-alpine/issues/255), and some reported issues fixed by switching to Debian or other OS. Might be worth switching to Debian despite the larger image size. Omg, that is surprising me... @ovizii Could you please help me try again the command in your host machine? Thank you. ``` ping -n -w 2 -c 1 ict.zfs.rent ``` If your host machine is working, than I believe that Alpine Docker is having a huge problem.
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@ovizii commented on GitHub (Sep 1, 2021):

@ovizii Could you please help me try again the command in your host machine? Thank you.

ping -n -w 2 -c 1 ict.zfs.rent

If your host machine is working, than I believe that Alpine Docker is having a huge problem.

here you go, that seems to have instantly worked:

 ping -n -w 2 -c 1 ict.zfs.rent
PING ict.zfs.rent (63.81.90.219) 56(84) bytes of data.
64 bytes from 63.81.90.219: icmp_seq=1 ttl=58 time=173 ms

--- ict.zfs.rent ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 172.686/172.686/172.686/0.000 ms
@ovizii commented on GitHub (Sep 1, 2021): > @ovizii Could you please help me try again the command in your host machine? Thank you. > > ``` > ping -n -w 2 -c 1 ict.zfs.rent > ``` > > If your host machine is working, than I believe that Alpine Docker is having a huge problem. here you go, that seems to have instantly worked: ``` ping -n -w 2 -c 1 ict.zfs.rent PING ict.zfs.rent (63.81.90.219) 56(84) bytes of data. 64 bytes from 63.81.90.219: icmp_seq=1 ttl=58 time=173 ms --- ict.zfs.rent ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 172.686/172.686/172.686/0.000 ms ```
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@ovizii commented on GitHub (Sep 1, 2021):

Please let me know if you think its my local system and not due to the alpine base image, I can do further tests.

@ovizii commented on GitHub (Sep 1, 2021): Please let me know if you think its my local system and not due to the alpine base image, I can do further tests.
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@louislam commented on GitHub (Sep 1, 2021):

Please let me know if you think its my local system and not due to the alpine base image, I can do further tests.

I have built a debian base image, I think it will eventually fix your problem.

uptime-kuma:1.5.2-debian
@louislam commented on GitHub (Sep 1, 2021): > Please let me know if you think its my local system and not due to the alpine base image, I can do further tests. I have built a debian base image, I think it will eventually fix your problem. ``` uptime-kuma:1.5.2-debian ```
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@ovizii commented on GitHub (Sep 1, 2021):

Thanks, I have switched to :1.5.2-debian and everything seems fine. I guess I'll check in a few weeks later and figure out how you are handling tags.
For now I'll keep using 1.5.2-debian - maybe later you'll have a generic :debian or whatever.

@ovizii commented on GitHub (Sep 1, 2021): Thanks, I have switched to :1.5.2-debian and everything seems fine. I guess I'll check in a few weeks later and figure out how you are handling tags. For now I'll keep using 1.5.2-debian - maybe later you'll have a generic :debian or whatever.
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@louislam commented on GitHub (Sep 1, 2021):

Thanks, I have switched to :1.5.2-debian and everything seems fine. I guess I'll check in a few weeks later and figure out how you are handling tags.
For now I'll keep using 1.5.2-debian - maybe later you'll have a generic :debian or whatever.

If Debian is better for most users, I will use Debian as main tag in the future. For example:

  • 1.6 (Debian)
  • 1.6-alpine (Alpine)
@louislam commented on GitHub (Sep 1, 2021): > Thanks, I have switched to :1.5.2-debian and everything seems fine. I guess I'll check in a few weeks later and figure out how you are handling tags. > For now I'll keep using 1.5.2-debian - maybe later you'll have a generic :debian or whatever. If Debian is better for most users, I will use Debian as main tag in the future. For example: - 1.6 (Debian) - 1.6-alpine (Alpine)
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@ovizii commented on GitHub (Sep 1, 2021):

Just wanted to let you know, that I have now added fixed DNS servers to uptime-kuma's docker-compose.yml file

    dns:
      - 1.1.1.1
      - 9.9.9.9
      - 8.8.8.8

Response times have gone seriously down compared to before. Before this, the docker host used to use a locally (Docker run) DNS (adguard home).

@ovizii commented on GitHub (Sep 1, 2021): Just wanted to let you know, that I have now added fixed DNS servers to uptime-kuma's docker-compose.yml file ``` dns: - 1.1.1.1 - 9.9.9.9 - 8.8.8.8 ``` Response times have gone seriously down compared to before. Before this, the docker host used to use a locally (Docker run) DNS (adguard home).
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@IIIdefconIII commented on GitHub (Oct 16, 2024):

Hi is there a fix in WIP? also the docker containers here are not been read anymore.

Thanks alot! Love this tools for a lon period now

@IIIdefconIII commented on GitHub (Oct 16, 2024): Hi is there a fix in WIP? also the docker containers here are not been read anymore. Thanks alot! Love this tools for a lon period now
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@IIIdefconIII commented on GitHub (Oct 16, 2024):

the docker sock does get read ibut the statusses are offline
image
image
as while those containers are up and running smooth

@IIIdefconIII commented on GitHub (Oct 16, 2024): the docker sock does get read ibut the statusses are offline ![image](https://github.com/user-attachments/assets/ea7d4104-d7fe-4749-975f-a79409eb5808) ![image](https://github.com/user-attachments/assets/7f76b710-ceb1-4a78-935a-8c44891f8eab) as while those containers are up and running smooth
deekerman commented 2026-02-28 01:37:44 -05:00
Author
Owner
Copy link

@IIIdefconIII commented on GitHub (Oct 16, 2024):

This is wait i get when i try to clean the database file

image

EDIT: Can anyone tell me how to unlock the database?
LOG:

[2023-04-14 03:14:07] [Error: insert into `heartbeat` (`down_count`, `duration`, `important`, `monitor_id`, `msg`, `ping`, `status`, `time`) values (0, 60, false, 14, '200 - OK', 51, 1, '2023-04-14 01:14:06.201') - SQLITE_BUSY: database is locked] {
@IIIdefconIII commented on GitHub (Oct 16, 2024): This is wait i get when i try to clean the database file ![image](https://github.com/user-attachments/assets/3de113b8-6f17-486d-8659-bef9eb37e3ed) EDIT: Can anyone tell me how to unlock the database? LOG: ``` [2023-04-14 03:14:07] [Error: insert into `heartbeat` (`down_count`, `duration`, `important`, `monitor_id`, `msg`, `ping`, `status`, `time`) values (0, 60, false, 14, '200 - OK', 51, 1, '2023-04-14 01:14:06.201') - SQLITE_BUSY: database is locked] { ```
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
npm-update
3.0.X
dev-better-auth
copilot/remove-password-complexity-requirements
2.2.X
copilot/sub-pr-6355
1.23.X
api-via-socketio-client
2.1.3
2.1.2
2.1.1
2.1.0
2.1.0-beta.3
2.1.0-beta.2
2.1.0-beta.1
2.1.0-beta.0
2.0.2
2.0.1
1.23.17
2.0.0
2.0.0-beta.4
2.0.0-beta.3
2.0.0-beta.2
2.0.0-beta.2-temp
2.0.0-beta.1
1.23.16
2.0.0-beta.0
1.23.15
1.23.14
1.23.13
1.23.12
1.23.11
1.23.10
1.23.9
1.23.8
1.23.7
1.23.6
1.23.5
1.23.5-beta.0
1.23.4
1.23.3
1.23.2
1.23.1
1.23.0
1.23.0-beta.1
1.23.0-beta.0
1.22.1
1.22.0
1.22.0-beta.0
1.21.3
1.21.2
1.21.2-beta.0
1.21.1
1.21.0
1.21.0-beta.1
1.21.0-beta.0
1.20.2
1.20.1
1.20.0
1.20.0-beta.0
1.19.6
1.19.5
1.19.4
1.19.3
1.19.2
1.19.1
1.19.0
1.19.0-beta.2
1.19.0-beta.1
1.19.0-beta.0
1.18.5
1.18.4
1.18.3
1.18.2
1.18.1
1.18.0
1.18.0-beta.0
1.17.1
1.17.0
1.17.0-beta.1
1.17.0-beta.0
1.16.1
1.16.0
1.16.0-beta.0
1.15.1
1.15.0
1.15.0-beta.1
1.14.1
1.15.0-beta.0
1.14.0
1.14.0-beta.2
1.13.2
1.14.0-beta.1
1.14.0-beta.0
1.13.1
1.13.0
1.13.0-beta.2
1.13.0-beta.1
1.13.0-beta.0
1.12.1
1.12.0
1.11.4
1.11.3
1.11.2
1.11.1
1.11.0
1.10.2
1.10.1
1.10.0
1.9.2
1.9.1
1.9.0
1.8.0
1.7.3
1.7.2
1.7.1
1.7.0
1.6.3
1.6.2
1.6.1
1.6.0
1.5.3
1.5.2
1.5.1
1.5.0
1.3.2
1.3.1
1.3.0
1.2.0
1.1.0
1.0.10
1.0.9
1.0.8
1.0.7
1.0.6
1.0.5
1.0.4
1.0.3
1.0.2
1.0.1
1.0.0
Labels
Clear labels   
A:accessibility

   
A:api

   
A:cert-expiry

   
A:core

   
A:dashboard

   
A:deployment

   
A:documentation

   
A:domain expiry

   
A:incidents

   
A:maintenance

   
A:metrics

   
A:monitor

   
A:notifications

   
A:reports

   
A:settings

   
A:status-page

   
A:ui/ux

   
A:user-management

   
Stale

   
ai-slop

   
blocked

   
blocked-upstream

   
bug

   
cannot-reproduce

   
dependencies

   
discussion

   
duplicate

   
feature-request

   
feature-request

   
good first issue

   
hacktoberfest

   
help

   
help wanted

   
house keeping

   
invalid

   
invalid-format

   
invalid-format

   
question

   
releaseblocker 🚨

   
security

   
spam

   
type:enhance-existing

   
type:new

   
wontfix
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uptime-kuma#177
No description provided.