starred/uptime-kuma

Fork 0

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

`monitor_uptime_ratio` and `monitor_response_time_seconds` still exposed in metrics when paused/deleted #4693

New issue

Open

opened 2026-02-28 04:12:05 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-28 04:12:05 -05:00

Owner

Originally created by @tr4nt0r on GitHub (Feb 10, 2026).

Possibly related: #6903

🛡️ Security Policy

I have read and agree to Uptime Kuma's Security Policy.

📝 Description

monitor_uptime_ratio and monitor_response_time_seconds still exposed in metrics when paused

👟 Reproduction steps

Delete or pause a monitor

👀 Expected behavior

When a monitor is paused or deleted, it is not exposed in /metrics endpoint anymore

😓 Actual Behavior

monitor_uptime_ratio and monitor_response_time_seconds are still exposed in metrics when monitor is paused or deleted, only a restart cleans up the metrics

🐻 Uptime-Kuma Version

2.1.0

💻 Operating System and Arch

CentOS Linux release 7.9.2009 (Core)

🌐 Browser

Chrome 44.0.7559.132

🖥️ Deployment Environment

Runtime Environment:
Database:
- SQLite: Embedded
Database Storage:
Uptime Kuma Setup:
- Number of monitors: 4

📝 Relevant log output

Originally created by @tr4nt0r on GitHub (Feb 10, 2026). ### 📑 I have found these related issues/pull requests Possibly related: #6903 ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description `monitor_uptime_ratio` and `monitor_response_time_seconds` still exposed in metrics when paused ### 👟 Reproduction steps Delete or pause a monitor ### 👀 Expected behavior When a monitor is paused or deleted, it is not exposed in `/metrics` endpoint anymore ### 😓 Actual Behavior `monitor_uptime_ratio` and `monitor_response_time_seconds` are still exposed in metrics when monitor is paused or deleted, only a restart cleans up the metrics ### 🐻 Uptime-Kuma Version 2.1.0 ### 💻 Operating System and Arch CentOS Linux release 7.9.2009 (Core) ### 🌐 Browser Chrome 44.0.7559.132 ### 🖥️ Deployment Environment - **Runtime Environment**: - **Database**: - SQLite: Embedded - **Database Storage**: - **Uptime Kuma Setup**: - Number of monitors: `4` ### 📝 Relevant log output ```bash session ```

deekerman added the

bug

label

2026-02-28 04:12:05 -05:00

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 10, 2026):

A monitor does not suddenly loose its uptime when paused. It still has uptime, it is just fixed.

No bug that I can see

@CommanderStorm commented on GitHub (Feb 10, 2026): A monitor does not suddenly loose its uptime when paused. It still has uptime, it is just fixed. No bug that I can see

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@tr4nt0r commented on GitHub (Feb 10, 2026):

@CommanderStorm Previously (<2.1.0) monitors were not exposed at all in the prometheus metrics when they were paused. Now when a monitor is paused all other metrics values stop being exposed, except these two. When I do a restart, the change takes effect and none of the metrics are exposed. Maybe a caching issue. Could it be that monitor_uptime_ratio and monitor_response_time_seconds are served from cache and the others are not?

@tr4nt0r commented on GitHub (Feb 10, 2026): @CommanderStorm Previously (<2.1.0) monitors were not exposed at all in the prometheus metrics when they were paused. Now when a monitor is paused all other metrics values stop being exposed, except these two. When I do a restart, the change takes effect and none of the metrics are exposed. Maybe a caching issue. Could it be that `monitor_uptime_ratio` and `monitor_response_time_seconds` are served from cache and the others are not?

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 10, 2026):

I don't know and would need to have a deeper look.
That part of the system is particularly hard to work with and fairly undertested

@CommanderStorm commented on GitHub (Feb 10, 2026): I don't know and would need to have a deeper look. That part of the system is particularly hard to work with and fairly undertested

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@tr4nt0r commented on GitHub (Feb 10, 2026):

I dived a bit into the code, but I'm not familiar with javascript/nodejs, so I'm not gonna submit a PR, but this should fix the issue. The remove method is responsible for removing the metrics when paused, but this does not happen as expected for the aforementioned values.

diff --git a/server/prometheus.js b/server/prometheus.js
index adc1872e..6637b9e1 100644
--- a/server/prometheus.js
+++ b/server/prometheus.js
@@ -245,8 +245,12 @@ class Prometheus {
         try {
             monitorCertDaysRemaining.remove(this.monitorLabelValues);
             monitorCertIsValid.remove(this.monitorLabelValues);
-            monitorUptimeRatio.remove(this.monitorLabelValues);
-            monitorAverageResponseTimeSeconds.remove(this.monitorLabelValues);
+            monitorUptimeRatio.remove({ ...this.monitorLabelValues, window: "1d" });
+            monitorUptimeRatio.remove({ ...this.monitorLabelValues, window: "30d" });
+            monitorUptimeRatio.remove({ ...this.monitorLabelValues, window: "365d" });
+            monitorAverageResponseTimeSeconds.remove({ ...this.monitorLabelValues, window: "1d" });
+            monitorAverageResponseTimeSeconds.remove({ ...this.monitorLabelValues, window: "30d" });
+            monitorAverageResponseTimeSeconds.remove({ ...this.monitorLabelValues, window: "365d" });
             monitorResponseTime.remove(this.monitorLabelValues);
             monitorStatus.remove(this.monitorLabelValues);
         } catch (e) {

@tr4nt0r commented on GitHub (Feb 10, 2026): I dived a bit into the code, but I'm not familiar with javascript/nodejs, so I'm not gonna submit a PR, but this should fix the issue. The `remove` method is responsible for removing the metrics when paused, but this does not happen as expected for the aforementioned values. ```patch diff --git a/server/prometheus.js b/server/prometheus.js index adc1872e..6637b9e1 100644 --- a/server/prometheus.js +++ b/server/prometheus.js @@ -245,8 +245,12 @@ class Prometheus { try { monitorCertDaysRemaining.remove(this.monitorLabelValues); monitorCertIsValid.remove(this.monitorLabelValues); - monitorUptimeRatio.remove(this.monitorLabelValues); - monitorAverageResponseTimeSeconds.remove(this.monitorLabelValues); + monitorUptimeRatio.remove({ ...this.monitorLabelValues, window: "1d" }); + monitorUptimeRatio.remove({ ...this.monitorLabelValues, window: "30d" }); + monitorUptimeRatio.remove({ ...this.monitorLabelValues, window: "365d" }); + monitorAverageResponseTimeSeconds.remove({ ...this.monitorLabelValues, window: "1d" }); + monitorAverageResponseTimeSeconds.remove({ ...this.monitorLabelValues, window: "30d" }); + monitorAverageResponseTimeSeconds.remove({ ...this.monitorLabelValues, window: "365d" }); monitorResponseTime.remove(this.monitorLabelValues); monitorStatus.remove(this.monitorLabelValues); } catch (e) { ```

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@tr4nt0r commented on GitHub (Feb 19, 2026):

@CommanderStorm Can we reopen this issue until it is fixed? Or do you still consider this not a bug?

@tr4nt0r commented on GitHub (Feb 19, 2026): @CommanderStorm Can we reopen this issue until it is fixed? Or do you still consider this not a bug?

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 19, 2026):

We close bugs once they are fixed in nigtly.
Too hard to manage otherwise.

@CommanderStorm commented on GitHub (Feb 19, 2026): We close bugs once they are fixed in nigtly. Too hard to manage otherwise.

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@tr4nt0r commented on GitHub (Feb 19, 2026):

nightly is master branch, right? Then it's still not fixed. PR is still open #6915 (Tut mir echt leid, wenn ich dich nerve 🥺)

@tr4nt0r commented on GitHub (Feb 19, 2026): nightly is master branch, right? Then it's still not fixed. PR is still open #6915 (Tut mir echt leid, wenn ich dich nerve 🥺)

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 19, 2026):

Yea, sorry. Currently exam phase here, so did not have time to test if that works (it looks good, but time..)

@CommanderStorm commented on GitHub (Feb 19, 2026): Yea, sorry. Currently exam phase here, so did not have time to test if that works (it looks good, but time..)

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@johntdyer commented on GitHub (Feb 23, 2026):

@CommanderStorm ... seems to pass https://github.com/louislam/uptime-kuma/pull/6915 . Does that mean its about to proceed and be merged? Would love to see this fixed so I can stop manually managing the fault state in home assistant.

@johntdyer commented on GitHub (Feb 23, 2026): @CommanderStorm ... seems to pass https://github.com/louislam/uptime-kuma/pull/6915 . Does that mean its about to proceed and be merged? Would love to see this fixed so I can stop manually managing the fault state in home assistant.

deekerman commented

2026-02-28 04:12:08 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 23, 2026):

Sorry, I still have exams.

seems to pass

You mean you have tested the PR and it works as expected?

@CommanderStorm commented on GitHub (Feb 23, 2026): Sorry, I still have exams. > seems to pass You mean you have tested the PR and it works as expected?