Version 1.7.0 breaks ping for local devices

deekerman commented

2026-02-28 01:41:01 -05:00

Owner

Originally created by @raspberrycoulis on GitHub (Sep 26, 2021).

Describe the bug
After updating to version 1.7.0, all my ping monitors for local devices are broken. Prior to v1.7.0 these worked just fine - for example:

Monitor type: Ping
Hostname: local IP address - i.e. 192.168.1.21

The above worked just fine before updating to v1.7.0, but now they're all borked.

To fix, I have to change to:

Monitor type: TCP Port
Hostname: local IP address - i.e. 192.168.1.21
Port: 80 (for example, I'm running Pi-Hole on the above local IP address so port 80 is the web UI).

Expected behavior
The pings should work still as nothing has changed. Testing manually via a terminal (i.e. ping 192.168.1.21 -c 10 works as expected. The expected behaviour is that the ping monitor should "just work".

Info
Uptime Kuma Version: 1.7.0
Using Docker?: Yes
Docker Version: 20.10.3 build b35e731
OS: Synology DSM
Browser: Brave / Chrome

Error Log
"Device name": Failing: ping: socket: Operation not permitted

Originally created by @raspberrycoulis on GitHub (Sep 26, 2021). **Describe the bug** After updating to version 1.7.0, all my ping monitors for local devices are broken. Prior to v1.7.0 these worked just fine - for example: Monitor type: Ping Hostname: local IP address - i.e. 192.168.1.21 The above worked just fine before updating to v1.7.0, but now they're all borked. To fix, I have to change to: Monitor type: TCP Port Hostname: local IP address - i.e. 192.168.1.21 Port: 80 (for example, I'm running Pi-Hole on the above local IP address so port 80 is the web UI). **Expected behavior** The pings should work still as nothing has changed. Testing manually via a terminal (i.e. `ping 192.168.1.21 -c 10` works as expected. The expected behaviour is that the ping monitor should "just work". **Info** Uptime Kuma Version: 1.7.0 Using Docker?: Yes Docker Version: 20.10.3 build b35e731 OS: Synology DSM Browser: Brave / Chrome **Error Log** `"Device name": Failing: ping: socket: Operation not permitted`

deekerman

2026-02-28 01:41:01 -05:00

closed this issue
added the
bug
label

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

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

Did you turn off NET_RAW?

@louislam commented on GitHub (Sep 26, 2021): Did you turn off NET_RAW? Maybe related issue: https://github.com/louislam/uptime-kuma/issues/373

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@raspberrycoulis commented on GitHub (Sep 27, 2021):

    cap_add:
      - NET_RAW

It was never set specifically in my Docker Compose file anyway. I've just added it and recreated the container, but still doesn't work.

To be clear, everything worked perfectly before I upgraded to v1.7.0. I made zero changes to my Docker Compose file. I simply ran docker-compose pull then docker-compose up -d to update and recreate the container.

This is my Docker Compose file for Uptime Kuma for reference (I've included the NET_RAW as this is currently what my current config looks like as per your suggestion):

  uptime-kuma:
    image: louislam/uptime-kuma
    container_name: uptime-kuma
    stdin_open: true
    cap_add:
      - NET_RAW
    tty: true
    networks:
        home-media:
            ipv4_address: 172.20.0.13
    restart: unless-stopped
    volumes:
      - ${UPTIME_KUMA_DATA_PATH}:/app/data
    ports:
      - 3001:3001

Some notes:

The network is just a set network I run my config on as this is part of a wide-range of services all done via one Compose file so keeping them on their own network works fine for me
The data path is defined in a .env file and works fine for me

@raspberrycoulis commented on GitHub (Sep 27, 2021): ```` cap_add: - NET_RAW ```` It was never set specifically in my Docker Compose file anyway. I've just added it and recreated the container, but still doesn't work. To be clear, everything worked perfectly before I upgraded to v1.7.0. I made zero changes to my Docker Compose file. I simply ran `docker-compose pull` then `docker-compose up -d` to update and recreate the container. This is my Docker Compose file for Uptime Kuma for reference (I've included the `NET_RAW` as this is currently what my current config looks like as per your suggestion): ```yaml uptime-kuma: image: louislam/uptime-kuma container_name: uptime-kuma stdin_open: true cap_add: - NET_RAW tty: true networks: home-media: ipv4_address: 172.20.0.13 restart: unless-stopped volumes: - ${UPTIME_KUMA_DATA_PATH}:/app/data ports: - 3001:3001 ``` Some notes: * The network is just a set network I run my config on as this is part of a wide-range of services all done via one Compose file so keeping them on their own network works fine for me * The data path is defined in a `.env` file and works fine for me

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@gaby commented on GitHub (Sep 27, 2021):

@louislam I think this is happening because of the changes in #436

@gaby commented on GitHub (Sep 27, 2021): @louislam I think this is happening because of the changes in #436

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

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

@louislam I think this is happening because of the changes in #436

As I cannot reproduce the problem, I am not 100% sure.

I suggest @raspberrycoulis should try louislam/uptime-kuma:1-alpine.

@louislam commented on GitHub (Sep 27, 2021): > @louislam I think this is happening because of the changes in #436 As I cannot reproduce the problem, I am not 100% sure. I suggest @raspberrycoulis should try `louislam/uptime-kuma:1-alpine`.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@raspberrycoulis commented on GitHub (Sep 27, 2021):

I suggest @raspberrycoulis should try louislam/uptime-kuma:1-alpine.

This fixes the issue @louislam - as in, the local pings work again.

@raspberrycoulis commented on GitHub (Sep 27, 2021): > I suggest @raspberrycoulis should try `louislam/uptime-kuma:1-alpine`. This fixes the issue @louislam - as in, the local pings work again.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@nbvcxz commented on GitHub (Sep 27, 2021):

@raspberrycoulis - could you paste the full docker-compose.yml? Here I can see only the service part, but to reproduce it, I'd like to have the same Docker network definitions. So far, I cannot reproduce it on Uptime Kuma 1.7.0 Debian - I'm pinging host IP eth0 (I guess this is what you mean local IP address) with no issues: 0ms response (as expected).

@nbvcxz commented on GitHub (Sep 27, 2021): @raspberrycoulis - could you paste the full `docker-compose.yml`? Here I can see only the service part, but to reproduce it, I'd like to have the same Docker network definitions. So far, I cannot reproduce it on Uptime Kuma 1.7.0 Debian - I'm pinging host IP eth0 (I guess this is what you mean _local IP address_) with no issues: 0ms response (as expected).

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@raspberrycoulis commented on GitHub (Sep 27, 2021):

@nbvcxz I would, but it's a relatively large file that also handles other services like Sonarr, Radarr, NZBGet etc., so I've simply provided the relevant parts for the Uptime Kuma container. I'll add as much as I can that will be relevant.

version: '3.5'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1-alpine
    container_name: uptime-kuma
    stdin_open: true
    cap_add:
      - NET_RAW
    tty: true
    networks:
        home-media:
            ipv4_address: 172.20.0.13
    restart: unless-stopped
    volumes:
      - ${UPTIME_KUMA_DATA_PATH}:/app/data
    ports:
      - 3001:3001

networks:
  home-media:
    driver: bridge
    name: home-media
    ipam:
        driver: default
        config:
        - subnet: 172.20.0.0/16
          gateway: 172.20.0.1
          ip_range: 127.20.0.1/24

And from my .env file:

UPTIME_KUMA_DATA_PATH=/volume1/docker/uptime-kuma/data

So with those combined, this is what you would expect from the docker-compose.yml file:

version: '3.5'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1-alpine
    container_name: uptime-kuma
    stdin_open: true
    cap_add:
      - NET_RAW
    tty: true
    networks:
        home-media:
            ipv4_address: 172.20.0.13
    restart: unless-stopped
    volumes:
      - /volume1/docker/uptime-kuma/data:/app/data
    ports:
      - 3001:3001

networks:
  home-media:
    driver: bridge
    name: home-media
    ipam:
        driver: default
        config:
        - subnet: 172.20.0.0/16
          gateway: 172.20.0.1
          ip_range: 127.20.0.1/24

NOTE: The file above is now using the 1-alpine image as recommended by @louislam earlier.

@raspberrycoulis commented on GitHub (Sep 27, 2021): @nbvcxz I would, but it's a relatively large file that also handles other services like Sonarr, Radarr, NZBGet etc., so I've simply provided the relevant parts for the Uptime Kuma container. I'll add as much as I can that will be relevant. ```yaml version: '3.5' services: uptime-kuma: image: louislam/uptime-kuma:1-alpine container_name: uptime-kuma stdin_open: true cap_add: - NET_RAW tty: true networks: home-media: ipv4_address: 172.20.0.13 restart: unless-stopped volumes: - ${UPTIME_KUMA_DATA_PATH}:/app/data ports: - 3001:3001 networks: home-media: driver: bridge name: home-media ipam: driver: default config: - subnet: 172.20.0.0/16 gateway: 172.20.0.1 ip_range: 127.20.0.1/24 ```` And from my `.env` file: ```` UPTIME_KUMA_DATA_PATH=/volume1/docker/uptime-kuma/data ```` So with those combined, this is what you would expect from the `docker-compose.yml` file: ```yaml version: '3.5' services: uptime-kuma: image: louislam/uptime-kuma:1-alpine container_name: uptime-kuma stdin_open: true cap_add: - NET_RAW tty: true networks: home-media: ipv4_address: 172.20.0.13 restart: unless-stopped volumes: - /volume1/docker/uptime-kuma/data:/app/data ports: - 3001:3001 networks: home-media: driver: bridge name: home-media ipam: driver: default config: - subnet: 172.20.0.0/16 gateway: 172.20.0.1 ip_range: 127.20.0.1/24 ```` **NOTE:** The file above is now using the `1-alpine` image as recommended by @louislam earlier.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@nbvcxz commented on GitHub (Sep 27, 2021):

Few more questions:

Is your working compose file 3.5 or 2.x? I got:

ERROR: The Compose file './docker-compose.yml' is invalid because:
networks.home-media.ipam.config value Additional properties are not allowed ('gateway', 'ip_range' were unexpected)

What is according the documentation: these parameters are from 2.x not from 3.x compose. btw. they are working with e.g. 2.4 compose
2. Is ip_range: 127.20.0.1/24 a typo? (127→172)

I still cannot reproduce it on Debian image. It can be caused by host OS settings. If it still persists, could you make the following tests:

docker exec -it --user 1000:1000 uptime-kuma /bin/bash -c "ping 192.168.1.21" I assume you are running default 1000:1000 user
docker exec -it --user uptime-kuma /bin/bash -c "ping 192.168.1.21" It will run ping as root from the container
If ping as root works, try to run your compose file with:

    environment:
      PUID: "0"
      PGID: "0"

It will run Uptime Kuma as root user (as before).

@nbvcxz commented on GitHub (Sep 27, 2021): Few more questions: 1. Is your working compose file `3.5` or `2.x`? I got: ``` ERROR: The Compose file './docker-compose.yml' is invalid because: networks.home-media.ipam.config value Additional properties are not allowed ('gateway', 'ip_range' were unexpected) ``` What is according [the documentation](https://docs.docker.com/compose/compose-file/compose-file-v3/#ipam): these parameters are from `2.x` not from `3.x` compose. _btw. they are working with e.g. 2.4 compose_ 2. Is `ip_range: 127.20.0.1/24` a typo? (127→172) I still cannot reproduce it on Debian image. It can be caused by host OS settings. If it still persists, could you make the following tests: 1. `docker exec -it --user 1000:1000 uptime-kuma /bin/bash -c "ping 192.168.1.21"` I assume you are running default 1000:1000 user 2. `docker exec -it --user uptime-kuma /bin/bash -c "ping 192.168.1.21"` It will run ping as root from the container 3. If ping as root works, try to run your compose file with: ``` environment: PUID: "0" PGID: "0" ``` It will run Uptime Kuma as root user (as before).

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

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

I think it is related to #373. The symptoms are very similar.

As Alpine is still working, it is probably not related to the user problem.

I suspect that it could be Synology DSM's Docker which disabled many Capability Keys by default.

@louislam commented on GitHub (Sep 27, 2021): I think it is related to #373. The symptoms are very similar. As Alpine is still working, it is probably not related to the user problem. I suspect that it could be Synology DSM's Docker which disabled many Capability Keys by default.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@raspberrycoulis commented on GitHub (Sep 28, 2021):

Yeah sorry @nbvcxz, that is quite a lot of info to ask for when I've already tried to explain that I've changed absolutely nothing other than update the image to v1.7.0... As I said, everything worked fine as per the compose file I've shared previously, but then the pings just stopped working after updating to v1.7.0.

Switching to the 1-alpine tag reverted the issue, which @louislam seems to think is related to the issue. I'll try running the container as root on the latest image, to see if this helps.

@raspberrycoulis commented on GitHub (Sep 28, 2021): Yeah sorry @nbvcxz, that is quite a lot of info to ask for when I've already tried to explain that I've changed absolutely nothing other than update the image to v1.7.0... As I said, everything worked fine as per the compose file I've shared previously, but then the pings just stopped working after updating to v1.7.0. Switching to the `1-alpine` tag reverted the issue, which @louislam seems to think is related to the issue. I'll try running the container as root on the latest image, to see if this helps.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@raspberrycoulis commented on GitHub (Sep 28, 2021):

Update: @louislam / @nbvcxz - running as root on the latest image resolves the issue, so definitely a permissions issue.

I'm using a compose file with version 3.5, so the parameters are:

    environment:
      - PUID=0
      - PGID=0

Hope this helps!

@raspberrycoulis commented on GitHub (Sep 28, 2021): Update: @louislam / @nbvcxz - running as root on the latest image resolves the issue, so definitely a permissions issue. I'm using a compose file with version 3.5, so the parameters are: ```yaml environment: - PUID=0 - PGID=0 ``` Hope this helps!

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

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

Update: @louislam / @nbvcxz - running as root on the latest image resolves the issue, so definitely a permissions issue.

I'm using a compose file with version 3.5, so the parameters are:
    environment:
      - PUID=0
      - PGID=0
Hope this helps!

Thanks for testing. With this, it is a bit different to the #373 issue.

I hope this is not a common issue, I still don't know how to reproduce this.

@louislam commented on GitHub (Sep 28, 2021): > Update: @louislam / @nbvcxz - running as root on the latest image resolves the issue, so definitely a permissions issue. > > I'm using a compose file with version 3.5, so the parameters are: > > ```yaml > environment: > - PUID=0 > - PGID=0 > ``` > > Hope this helps! Thanks for testing. With this, it is a bit different to the #373 issue. I hope this is not a common issue, I still don't know how to reproduce this.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@elkaboing commented on GitHub (Sep 28, 2021):

I ran into the same issue. Updated my docker container this afternoon and when I brought the service back up, all my local pings were failing with

Monitor #18 'server': Failing: ping: socket: Operation not permitted
 | Interval: 60 seconds | Type: ping

Adding the root privileges to the environment section fixed the issue.

Here's my current docker-compose file (after adding PUID=0 and PGID=0) which is working as expected:

version: "3.7"

networks:
  t2_proxy:
    external:
      name: tfk_proxy

services:

  uptime:
    image: louislam/uptime-kuma
    container_name: uptime
    restart: unless-stopped
    networks:
      - tfk_proxy
    security_opt:
      - no-new-privileges:true
    environment:
      - PUID=0
      - PGID=0
    volumes:
      - $DOCKER/uptime:/app/data
    ports:
      - 3001:3001

@elkaboing commented on GitHub (Sep 28, 2021): I ran into the same issue. Updated my docker container this afternoon and when I brought the service back up, all my local pings were failing with ``` Monitor #18 'server': Failing: ping: socket: Operation not permitted | Interval: 60 seconds | Type: ping ``` Adding the root privileges to the environment section fixed the issue. Here's my current docker-compose file (after adding PUID=0 and PGID=0) which is working as expected: ``` version: "3.7" networks: t2_proxy: external: name: tfk_proxy services: uptime: image: louislam/uptime-kuma container_name: uptime restart: unless-stopped networks: - tfk_proxy security_opt: - no-new-privileges:true environment: - PUID=0 - PGID=0 volumes: - $DOCKER/uptime:/app/data ports: - 3001:3001 ```

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

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

May consider to change the default user back to root.

@louislam commented on GitHub (Sep 29, 2021): May consider to change the default user back to `root`.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

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

Fixed in 1.7.1.

Will try to find out how to reproduce the problem.

@louislam commented on GitHub (Sep 29, 2021): Fixed in 1.7.1. Will try to find out how to reproduce the problem.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@aniqueta commented on GitHub (Jan 11, 2023):

@louislam I'm experiencing this issue now in 1.94.1. I did not experience this in prior versions. The last version I was on was before 1.7 (unfortunately, I did not note it, as I've not had problems before).

I receive the following error:

ping.probe: there was an error while executing the ping program. . Check the path or permissions…

The environment is running uptime-kuma on Ubuntu 22.04.1 without Docker, but as its own user through systemd.

I am able to use the ping command via that user, so I don't believe there's a permissions or path issue.

Appreciate any help troubleshooting. Thanks.

@aniqueta commented on GitHub (Jan 11, 2023): @louislam I'm experiencing this issue now in 1.94.1. I did not experience this in prior versions. The last version I was on was before 1.7 (unfortunately, I did not note it, as I've not had problems before). I receive the following error: ``` ping.probe: there was an error while executing the ping program. . Check the path or permissions… ``` The environment is running uptime-kuma on Ubuntu 22.04.1 without Docker, but as its own user through systemd. I am able to use the ping command via that user, so I don't believe there's a permissions or path issue. Appreciate any help troubleshooting. Thanks.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@louislam commented on GitHub (Jan 11, 2023):

@aniqueta We changed the ping library in 1.19.4. Can you try 1.19.3?

cc: @Computroniks

@louislam commented on GitHub (Jan 11, 2023): @aniqueta We changed the ping library in 1.19.4. Can you try 1.19.3? cc: @Computroniks Related issue: https://github.com/danielzzz/node-ping/issues/105

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@louislam commented on GitHub (Jan 11, 2023):

Just my guess:

For systemd, environment path is not added by default. So Uptime Kuma cannot find the ping command.
https://askubuntu.com/questions/1014480/how-do-i-add-bin-to-path-for-a-systemd-service

If it is true, that is why the old implementation is hardcoded the full path of ping /bin/ping. (https://github.com/louislam/uptime-kuma/issues/2126)

@louislam commented on GitHub (Jan 11, 2023): Just my guess: For systemd, environment path is not added by default. So Uptime Kuma cannot find the ping command. https://askubuntu.com/questions/1014480/how-do-i-add-bin-to-path-for-a-systemd-service If it is true, that is why the old implementation is hardcoded the full path of ping `/bin/ping`. (https://github.com/louislam/uptime-kuma/issues/2126)

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@Computroniks commented on GitHub (Jan 11, 2023):

Not sure it is a path issue. Pm2 seems to inject the current environment of the user when starting the process https://pm2.keymetrics.io/docs/usage/environment/. The error message is just a message shown on any general ping error where there was an issue with the module using the ping binary.

Edit, just realised that you are using systemd on its own without pm2, in which case as @louislam says, you will need to edit the system file to include the environment. I am interested, why not just use pm2?

@Computroniks commented on GitHub (Jan 11, 2023): Not sure it is a path issue. Pm2 seems to inject the current environment of the user when starting the process https://pm2.keymetrics.io/docs/usage/environment/. The error message is just a message shown on any general ping error where there was an issue with the module using the ping binary. Edit, just realised that you are using systemd on its own without pm2, in which case as @louislam says, you will need to edit the system file to include the environment. I am interested, why not just use pm2?

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@Computroniks commented on GitHub (Jan 11, 2023):

Given that you say you have created another account, it might be a permissions error. Try running the process as your normal account and see if it works then.

@Computroniks commented on GitHub (Jan 11, 2023): Given that you say you have created another account, it might be a permissions error. Try running the process as your normal account and see if it works then.

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@aniqueta commented on GitHub (Jan 11, 2023):

Thanks for the super fast replies.

Downgrading to 1.19.3 resolved the issue.

The $PATH variable had been already set correctly in the systemd service file.

I'm able to run the ping commend from command line correctly as the specified user and running as a normal user still produced the ping error.

I didn't use pm2, since a) this is a low memory deployment (512MB), and while it didn't take much more memory, it was enough that I got OOM errors when running apt upgrade for example, and b) I don't have a need to use pm2 for other services, so it would hinder consistency and familiarity of tools across my services. It wasn't difficult at all to use systemd.

So it seems like something with the new library?

@aniqueta commented on GitHub (Jan 11, 2023): Thanks for the super fast replies. Downgrading to 1.19.3 resolved the issue. The $PATH variable had been already set correctly in the systemd service file. I'm able to run the ping commend from command line correctly as the specified user and running as a normal user still produced the ping error. I didn't use pm2, since a) this is a low memory deployment (512MB), and while it didn't take much more memory, it was enough that I got OOM errors when running apt upgrade for example, and b) I don't have a need to use pm2 for other services, so it would hinder consistency and familiarity of tools across my services. It wasn't difficult at all to use systemd. So it seems like something with the new library?

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@louislam commented on GitHub (Jan 11, 2023):

Thanks for the super fast replies.

Downgrading to 1.19.3 resolved the issue.

The $PATH variable had been already set correctly in the systemd service file.

I'm able to run the ping commend from command line correctly as the specified user and running as a normal user still produced the ping error.

I didn't use pm2, since a) this is a low memory deployment (512MB), and while it didn't take much more memory, it was enough that I got OOM errors when running apt upgrade for example, and b) I don't have a need to use pm2 for other services, so it would hinder consistency and familiarity of tools across my services. It wasn't difficult at all to use systemd.

So it seems like something with the new library?

Can you share your service file?

I just tested with wiki's service file, cannot reproduce your problem:
https://github.com/louislam/uptime-kuma/wiki/Systemd-Unit-File

@louislam commented on GitHub (Jan 11, 2023): > Thanks for the super fast replies. > > Downgrading to 1.19.3 resolved the issue. > > The $PATH variable had been already set correctly in the systemd service file. > > I'm able to run the ping commend from command line correctly as the specified user and running as a normal user still produced the ping error. > > I didn't use pm2, since a) this is a low memory deployment (512MB), and while it didn't take much more memory, it was enough that I got OOM errors when running apt upgrade for example, and b) I don't have a need to use pm2 for other services, so it would hinder consistency and familiarity of tools across my services. It wasn't difficult at all to use systemd. > > So it seems like something with the new library? Can you share your service file? I just tested with wiki's service file, cannot reproduce your problem: https://github.com/louislam/uptime-kuma/wiki/Systemd-Unit-File

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@louislam commented on GitHub (Jan 11, 2023):

Anyway, I managed to handle this by forking the node-ping project. It will be released along with 1.19.5
github.com/louislam/node-ping@1fdac27526

@louislam commented on GitHub (Jan 11, 2023): Anyway, I managed to handle this by forking the `node-ping` project. It will be released along with 1.19.5 https://github.com/louislam/node-ping/commit/1fdac27526e1552df9ca74b7acf63277d7077ac2

deekerman commented

2026-02-28 01:41:08 -05:00

Author

Owner

@RyderCragie commented on GitHub (Jan 5, 2025):

@louislam I am having this issue too.

https://www.reddit.com/r/UptimeKuma/comments/1htdgc9/false_intermittent_downtime/

@RyderCragie commented on GitHub (Jan 5, 2025): @louislam I am having this issue too. https://www.reddit.com/r/UptimeKuma/comments/1htdgc9/false_intermittent_downtime/ <img width="318" alt="Screenshot 2025-01-05 at 18 52 34" src="https://github.com/user-attachments/assets/f4a15b53-47dd-4a65-9030-d4491bd549d9" />

Rows
Columns

Version 1.7.0 breaks ping for local devices #274