I successfully setup and tested the docker host in UptimeKuma. But when I add monitors for docker name, they all fail with 'Request failed with status code 404' 

Any help would be greatly appreciated.

21 minutes ago, gurulee said:

I successfully setup and tested the docker host in UptimeKuma. But when I add monitors for docker name, they all fail with 'Request failed with status code 404' 

Any help would be greatly appreciated.

Use the IP and port instead.

19 hours ago, CorneliousJD said:

Use the IP and port instead.

What is the purpose of the Docker setup and docker monitoring type in Uptimekuma then?

Just now, gurulee said:

What is the purpose of the Docker setup and docker monitoring type in Uptimekuma then?

I'm not the developer. 

I do suspect there's an incompatibility in the way unraid handles docker and kumas built in method perhaps. 

 

I haven't personally investigated. 

6 hours ago, gurulee said:

What is the purpose of the Docker setup and docker monitoring type in Uptimekuma then?

 

6 hours ago, CorneliousJD said:

I'm not the developer. 

I do suspect there's an incompatibility in the way unraid handles docker and kumas built in method perhaps. 

 

I haven't personally investigated. 

 

Docker monitoring works fine for me.  One thing you do need to do that is not part of the template is add a read only path for /var/run

 

On 8/29/2024 at 3:36 PM, nerbonne said:

 

 

Docker monitoring works fine for me.  One thing you do need to do that is not part of the template is add a read only path for /var/run

 

So I already had that in my docker template. What resolved it for me was to use the docker container ID in the monitor instead of the docker name.

Edited September 3, 20241 yr by gurulee

47 minutes ago, gurulee said:

So I already had that in my docker template. What resolved it for me was to use the docker container ID in the monitor instead of the docker name.

 

Not sure what name you are trying, but if you use the name of the container as retrieved by this command, it will work:

 

docker ps --format ‘{{.Names}}’

 

3 hours ago, nerbonne said:

 

Not sure what name you are trying, but if you use the name of the container as retrieved by this command, it will work:

 

docker ps --format ‘{{.Names}}’

 

Turns out using the container ID is no good since it changes when you update the docker. 

I tried using the name of the docker as it shows on my dockers page in the webui. 

3 hours ago, nerbonne said:

 

Not sure what name you are trying, but if you use the name of the container as retrieved by this command, it will work:

 

docker ps --format ‘{{.Names}}’

 

Thanks! The docker names must be lower case and match the results of the cmd you provided. 👍

I'm having difficulty configuring the UptimeKuma container to work with Tailscale. When I enable the 'use Tailscale' option in the environment settings, one of two problems occurs:

• The container fails to start up completely, or
• It somehow overwrites my Unraid host plugin's Tailscale configuration

This issue appears to be specific to the UptimeKuma container, as my other containers work fine with Tailscale. I suspect there's something unique about UptimeKuma's configuration that's causing conflicts.

 

Has anyone successfully exposed their UptimeKuma container through Tailscale? If so, could you share your configuration approach? I'd appreciate any working examples or specific settings that resolved similar issues.

Aha, I've figured out the solution! The issue was with the Tailscale state directory configuration, or lack thereof.
 

For anyone else facing this problem, you need to manually set the Tailscale state directory in the DockerMan web interface for the UptimeKuma container. Specifically, I set it to:

/mnt/user/appdata/uptimekuma/.tailscale

This prevents the container from interfering with the host's Tailscale configuration and resolves the startup failures.

I've created a gist with my full working configuration that you can reference.  This is the content from /boot/config/plugins/dockerMan/templates-user/my-UptimeKuma.xml

 

This approach maintains proper isolation between the container's Tailscale instance and the host system. Hope this helps anyone else who runs into the same issue!

On 2/28/2025 at 11:29 PM, gvns said:

Aha, I've figured out the solution! The issue was with the Tailscale state directory configuration, or lack thereof.
 

For anyone else facing this problem, you need to manually set the Tailscale state directory in the DockerMan web interface for the UptimeKuma container. Specifically, I set it to:

/mnt/user/appdata/uptimekuma/.tailscale

This prevents the container from interfering with the host's Tailscale configuration and resolves the startup failures.

I've created a gist with my full working configuration that you can reference.  This is the content from /boot/config/plugins/dockerMan/templates-user/my-UptimeKuma.xml

 

This approach maintains proper isolation between the container's Tailscale instance and the host system. Hope this helps anyone else who runs into the same issue!

I encountered this issue on another thread (see below), and the root issue is slightly different:

 

This container maps all of /var/run from the host into the container. This appears to be so that the container can access the docker socket (/var/run/docker.sock), but the container actually gets all of the data in /var/run, including the Tailscale socket in /var/run/tailscale/tailscaled.sock.

 

The "correct" way to fix the issue is to remove the "Docker Socket" mapping from the template. If you need the Docker socket, you can instead map it directly by creating a new mapping for /var/run/docker.sock -> /var/run/docker.sock

11 hours ago, EDACerton said:

I encountered this issue on another thread (see below), and the root issue is slightly different:

 

This container maps all of /var/run from the host into the container. This appears to be so that the container can access the docker socket (/var/run/docker.sock), but the container actually gets all of the data in /var/run, including the Tailscale socket in /var/run/tailscale/tailscaled.sock.

 

The "correct" way to fix the issue is to remove the "Docker Socket" mapping from the template. If you need the Docker socket, you can instead map it directly by creating a new mapping for /var/run/docker.sock -> /var/run/docker.sock

Thanks for this - I've merged your PR to github

On 4/14/2025 at 7:24 PM, EDACerton said:

I encountered this issue on another thread (see below), and the root issue is slightly different:

 

This container maps all of /var/run from the host into the container. This appears to be so that the container can access the docker socket (/var/run/docker.sock), but the container actually gets all of the data in /var/run, including the Tailscale socket in /var/run/tailscale/tailscaled.sock.

 

The "correct" way to fix the issue is to remove the "Docker Socket" mapping from the template. If you need the Docker socket, you can instead map it directly by creating a new mapping for /var/run/docker.sock -> /var/run/docker.sock

Aha, thanks for catching this. I am not super familiar with Docker socket functionality so I've always avoided fiddling with this. Removing it when necessary seems a much better solution.

Any chance this gets an update? Seems like it's stuck at 1.23.6 whereas there's a second beta of 2.0

3 hours ago, Krakout said:

Any chance this gets an update? Seems like it's stuck at 1.23.6 whereas there's a second beta of 2.0

just change the tag if you want to use the beta version.
i.e louislam/uptime-kuma:2.0.0-beta.2

On 5/7/2025 at 12:18 PM, Mainfrezzer said:

just change the tag if you want to use the beta version.
i.e louislam/uptime-kuma:2.0.0-beta.2

Oh cool, will try that. Thanks!

On 5/7/2025 at 5:18 AM, Mainfrezzer said:

just change the tag if you want to use the beta version.
i.e louislam/uptime-kuma:2.0.0-beta.2

Hello! Is there a list on which versions are mapped to the tags show here? https://hub.docker.com/r/louislam/uptime-kuma/

I am using the "latest" tag however it is running Version: 1.23.17. I know I can manually select a version, however my goal is to use a tag that downloads whatever the latest stable version is. Thanks for the assistance!

8 minutes ago, bradrel said:

Hello! Is there a list on which versions are mapped to the tags show here? https://hub.docker.com/r/louislam/uptime-kuma/

I am using the "latest" tag however it is running Version: 1.23.17. I know I can manually select a version, however my goal is to use a tag that downloads whatever the latest stable version is. Thanks for the assistance!

See here: https://github.com/louislam/uptime-kuma/wiki/Migration-From-v1-To-v2

The tag "2" will give you latest v2 stable.

8 minutes ago, CorneliousJD said:

See here: https://github.com/louislam/uptime-kuma/wiki/Migration-From-v1-To-v2

The tag "2" will give you latest v2 stable.

Ah great. Thank you!

I need some help from a guru, I have uptime Kuma working great and I have it sending a notification message to a teams group using Power automate since Webhooks are being discontinued. so here is where I am at, I can get the message to fire when something goes down and I get teams message however its not pulling any of the ServerID info from uptime. I am only getting Server: Unknown instead of the name of the device. I can see that the info is getting sent to power automate because I see it in the log. I am brand new to power automate so IM sure its something I am or am not doing. would anyone be willing to help me get the power automate configured properly to show the right info?

Here is a test I ran, You can see on the output on the left the data is pulled. I just dont know how to pull that data to send the message.

Edited March 27Mar 27 by tmoran000

Would you mind updating this template to the current version of uptime-kuma 2.x.x?

Thanks!

16 hours ago, shawnb said:

Would you mind updating this template to the current version of uptime-kuma 2.x.x?

Thanks!

Change :latest to :2

Hey everyone! I built an Unraid plugin that brings Uptime Kuma monitor statuses directly onto the Unraid dashboard as a native widget.

What it does:

- Displays heartbeat bars matching Uptime Kuma's style (green/red/orange/blue) with hover tooltips showing date/time and status

- Uptime percentage badges with color coding

- Configurable time periods (1h, 12h, 24h, 7d, 30d, 90d, 180d)

- Quick link to open Uptime Kuma's WebUI (auto-detected from your Docker container)

- Choose which monitors to display via checkboxes in settings

- Native Unraid dashboard tile with standard controls (settings cog, collapse, etc.)

How it works:

It reads Uptime Kuma's SQLite database directly in read-only mode from the Docker volume mount. No API keys, no background services, no modifications to Uptime Kuma. Supports both v1.x and v2.x (auto-detected).

Install:

Plugins tab > Install Plugin > paste this URL:

https://raw.githubusercontent.com/drohack/UptimeKumaPlugin/main/uptime-kuma.plg

Then go to the plugin settings, set your database path (usually /mnt/user/appdata/uptimekuma/kuma.db), click Test Connection, enable the widget, and check your dashboard.

GitHub: https://github.com/drohack/UptimeKumaPlugin

Feedback and suggestions welcome!

On 3/29/2026 at 5:15 PM, CorneliousJD said:

Change :latest to :2

Can you update the Docker Container Template in the CA with the latest Changes like Version 2 and others? So have new Installations directly the newest Version and Changes and not Version 1 with the manually Upgrade.

Edited June 27Jun 27 by Revan335