starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

When uptime-kuma is offline and back online, the status report lead to wrong assertions to services status #4044

New issue

Open

opened 2026-02-28 03:49:09 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-28 03:49:09 -05:00

Owner

Originally created by @Fade78 on GitHub (Mar 19, 2025).

It's very hard to formulate but I didn't find any issues about "offline" or "take into account".

🛡️ Security Policy

I agree to have read this project Security Policy

Description

I have a host with many VMs with services and also the uptime-kuma instance. Sometimes, I power the entire host off. When it's back online, the open-kuma instance reports one little red bar and all the other are green. At a glance, I could say there was a little downtime while in fact it was for hours.

What is displayed by uptime-kuma.

The red bar is dated: 2025-03-19 06:07
The green bar just at its right is dated: 2025-03-18 06:12, as expected
The green bar just at its left is dated: 2025-03-18 22:00, which is 8H before

Looking at this bar you can say that nothing happened, maybe a little interruption. But in fact it was a entire night off. The actual truth should be the following:

What should be displayed by uptime-kuma (Yes, I made this image myself, that's how I care about this bug and this software).

👟 Reproduction steps

Try to shutdown an instance of open-kuma for hours.

👀 Expected behavior

There should be a special color, maybe gray, to indicate that no check could be performed and everything should be proportional to time, not probe activations.

😓 Actual Behavior

Lies about uptimes of monitored services:

What is displayed by uptime-kuma: everything is fine, nothing to see, a little glitch

🐻 Uptime-Kuma Version

1.23.16

💻 Operating System and Arch

Ubuntu server 24.04 docker host, using official uptime-kuma container

🌐 Browser

Firefox

🖥️ Deployment Environment

Runtime: Docker 26.1.3
Database: The one in the container.
Filesystem used to store the database on: ext4
number of monitors: 10

📝 Relevant log output

Originally created by @Fade78 on GitHub (Mar 19, 2025). ### 📑 I have found these related issues/pull requests It's very hard to formulate but I didn't find any issues about "offline" or "take into account". ### 🛡️ Security Policy - [x] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description I have a host with many VMs with services and also the uptime-kuma instance. Sometimes, I power the entire host off. When it's back online, the open-kuma instance reports one little red bar and all the other are green. At a glance, I could say there was a little downtime while in fact it was for hours. ![Image](https://github.com/user-attachments/assets/a5dd202c-a393-4b47-b6f0-3df1db5712b2) _What is displayed by uptime-kuma._ * The red bar is dated: 2025-03-19 06:07 * The green bar just at its right is dated: 2025-03-18 06:12, as expected * The green bar just at its left is dated: 2025-03-18 22:00, which is 8H before Looking at this bar you can say that nothing happened, maybe a little interruption. But in fact it was a entire night off. The actual truth should be the following: ![Image](https://github.com/user-attachments/assets/2a1b5250-f9eb-403d-b49d-97b44d569f80) _What should be displayed by uptime-kuma (Yes, I made this image myself, that's how I care about this bug and this software)._ ### 👟 Reproduction steps Try to shutdown an instance of open-kuma for hours. ### 👀 Expected behavior There should be a special color, maybe gray, to indicate that no check could be performed and everything should be proportional to time, not probe activations. ![Image](https://github.com/user-attachments/assets/2a1b5250-f9eb-403d-b49d-97b44d569f80) ### 😓 Actual Behavior Lies about uptimes of monitored services: ![Image](https://github.com/user-attachments/assets/a5dd202c-a393-4b47-b6f0-3df1db5712b2) _What is displayed by uptime-kuma: everything is fine, nothing to see, a little glitch_ ### 🐻 Uptime-Kuma Version 1.23.16 ### 💻 Operating System and Arch Ubuntu server 24.04 docker host, using official uptime-kuma container ### 🌐 Browser Firefox ### 🖥️ Deployment Environment - **Runtime**: Docker 26.1.3 - Database: The one in the container. - Filesystem used to store the database on: ext4 - number of monitors: 10 ### 📝 Relevant log output ```shell ```

deekerman added the

feature-request

A:dashboard

A:monitor

labels

2026-02-28 03:49:09 -05:00

deekerman commented

2026-02-28 03:49:14 -05:00

Author

Owner

@louislam commented on GitHub (Mar 19, 2025):

Unfortunately, Uptime Kuma was not designed like that, it is a normal by current design.

@louislam commented on GitHub (Mar 19, 2025): Unfortunately, Uptime Kuma was not designed like that, it is a normal by current design.

deekerman commented

2026-02-28 03:49:14 -05:00

Author

Owner

@Fade78 commented on GitHub (Mar 20, 2025):

But this is a purely functional limitation, right? The application already have, in fact, the information because it displays it in the main dashboard:

So it would be possible to recreate the status page from this information. Maybe as a configurable option?

@Fade78 commented on GitHub (Mar 20, 2025): But this is a purely functional limitation, right? The application already have, in fact, the information because it displays it in the main dashboard: ![Image](https://github.com/user-attachments/assets/9dabc906-4a2e-4efc-95b1-aeb8968d688f) So it would be possible to recreate the status page from this information. Maybe as a configurable option?

deekerman commented

2026-02-28 03:49:14 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Mar 24, 2025):

Current implementation for the heartbeat bar just looks at the last n heartbeats. If one is missing that is thus not known.

The chart below is a much newer implementation using the aggregator.

@CommanderStorm commented on GitHub (Mar 24, 2025): Current implementation for the heartbeat bar just looks at the last n heartbeats. If one is missing that is thus not known. The chart below is a much newer implementation using the aggregator.

deekerman commented

2026-02-28 03:49:14 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Mar 24, 2025):

(talking about v2)

@CommanderStorm commented on GitHub (Mar 24, 2025): (talking about v2)

deekerman commented

2026-02-28 03:49:14 -05:00

Author

Owner

@Fade78 commented on GitHub (Mar 25, 2025):

(talking about v2)

If it can boost the priority of this feature for v2, please consider that in case the uptime-kuma is down and then recover because of a global outage, a client may sue the service provider company about giving false information about the uptime. Behind this, there's maybe penalties to pay because of the SLA and the service provider could be accused to conceal the actual downtime.

@Fade78 commented on GitHub (Mar 25, 2025): > (talking about v2) If it can boost the priority of this feature for v2, please consider that in case the uptime-kuma is down and then recover because of a global outage, a client may sue the service provider company about giving false information about the uptime. Behind this, there's maybe penalties to pay because of the SLA and the service provider could be accused to conceal the actual downtime.

deekerman commented

2026-02-28 03:49:14 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Mar 25, 2025):

First of all, your monitoring should be external, NOT internal => not experience the same faults.

How SLA-rebates usually work is that the client has to notice a fault and then report it via a ticket to get a rebate. I don't see how this is affected.
If you are handling this level of big tech, you likely have your own system for this.

For SLAs you also want custom accounting. How are you handling maintenance/pausing/retries/...
Adding different accounting modes is not planned.

@CommanderStorm commented on GitHub (Mar 25, 2025): First of all, your monitoring should be external, NOT internal => not experience the same faults. How SLA-rebates usually work is that the client has to notice a fault and then report it via a ticket to get a rebate. I don't see how this is affected. If you are handling this level of big tech, you likely have your own system for this. For SLAs you also want custom accounting. How are you handling maintenance/pausing/retries/... Adding different accounting modes is not planned.