starred/uptime-kuma

Fork 0

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

Manual database changes not reflecting in Uptime Kuma while app is running #1213

New issue

Closed

opened 2026-02-28 02:13:43 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 02:13:43 -05:00

Owner

Originally created by @joe-eklund on GitHub (Jun 26, 2022).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

Description

Hello-

I am attempting to change some values in the database directly with DB Browser for SQLite. For example, flipping the active value of a monitor from 1 to 0. When I do this while Uptime Kuma is not running, when I start up Uptime Kuma it picks up my changes just fine.

But when Uptime Kuma is already running and I attempt to make this change to the database, those changes are not reflected in Uptime Kuma. And then when I do something in Uptime Kuma that requires an update to the database (say changing the name of a monitor), the changes I made through DB Browser are overwritten like they never happened.

I get the same behavior when I use Python to interact with the database. I am also getting some other weird behavior that seems inconsistent regarding changes not persisting when they are done across different clients (UK, DB Browser, and Python), but I think they are all related to some underlying issue. This is just a hunch, and once this issue is resolved, if those other problems persist I can make new issue(s).

👟 Reproduction steps

Spin down Uptime Kuma.
Modify a monitor's active value in the database directly using something like DB Browser.
Spin up Uptime Kuma, and see it picks up the change. Yay.
Then attempt to change it again using DB Browser. Uptime Kuma does not pick up the change. Not yay.

👀 Expected behavior

The expected behavior is that making changes to the database should be accurately reflected in Uptime Kuma, especially when Uptime Kuma is running. And when changes are made in Uptime Kuma, they should not overwrite the changes I made to the database directly.

This expected behavior does work like this when I interact with the database with my python API and DB Browser (with Uptime Kuma spun down). Meaning if I update the database with DB Browser, my Python API (which is using the same database) does accurately see the changes. And when I make changes to the database through my Python API, DB Browser sees the changes correctly.

I would like this behavior to also work with Uptime Kuma, that way I can manually update the database without having to spin down Uptime Kuma.

😓 Actual Behavior

Instead, UK does not see the changes I made to the database, and will overwrite my manual changes when it makes its own update to the database.

🐻 Uptime-Kuma Version

1.17.0

💻 Operating System and Arch

MacOS 11.6.6

🌐 Browser

Chrome Version 102.0.5005.115

🐋 Docker Version

Docker version 20.10.12, build e91ed5707e

🟩 NodeJS Version

No response

📝 Relevant log output

N/A.

Originally created by @joe-eklund on GitHub (Jun 26, 2022). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description Hello- I am attempting to change some values in the database directly with [DB Browser for SQLite](https://sqlitebrowser.org/). For example, flipping the `active` value of a monitor from `1` to `0`. When I do this while Uptime Kuma is **not** running, when I start up Uptime Kuma it picks up my changes just fine. But when Uptime Kuma is _already_ running and I attempt to make this change to the database, those changes are _not_ reflected in Uptime Kuma. And then when I do something in Uptime Kuma that requires an update to the database (say changing the name of a monitor), the changes I made through DB Browser are overwritten like they never happened. I get the same behavior when I use Python to interact with the database. I am also getting some other weird behavior that seems inconsistent regarding changes not persisting when they are done across different clients (UK, DB Browser, and Python), but I think they are all related to some underlying issue. This is just a hunch, and once this issue is resolved, if those other problems persist I can make new issue(s). ### 👟 Reproduction steps 1. Spin down Uptime Kuma. 2. Modify a monitor's `active` value in the database directly using something like DB Browser. 3. Spin up Uptime Kuma, and see it picks up the change. Yay. 4. Then attempt to change it again using DB Browser. Uptime Kuma does _not_ pick up the change. Not yay. ### 👀 Expected behavior The expected behavior is that making changes to the database should be accurately reflected in Uptime Kuma, especially when Uptime Kuma is running. And when changes are made in Uptime Kuma, they should not overwrite the changes I made to the database directly. This expected behavior does work like this when I interact with the database with my python API and DB Browser (with Uptime Kuma spun down). Meaning if I update the database with DB Browser, my Python API (which is using the same database) does accurately see the changes. And when I make changes to the database through my Python API, DB Browser sees the changes correctly. I would like this behavior to also work with Uptime Kuma, that way I can manually update the database without having to spin down Uptime Kuma. ### 😓 Actual Behavior Instead, UK does not see the changes I made to the database, and will overwrite my manual changes when it makes its own update to the database. ### 🐻 Uptime-Kuma Version 1.17.0 ### 💻 Operating System and Arch MacOS 11.6.6 ### 🌐 Browser Chrome Version 102.0.5005.115 ### 🐋 Docker Version Docker version 20.10.12, build e91ed5707e ### 🟩 NodeJS Version _No response_ ### 📝 Relevant log output ```shell N/A. ```

deekerman

2026-02-28 02:13:43 -05:00

closed this issue
added the
feature-request

wontfix

A:deployment
labels

deekerman commented

2026-02-28 02:13:48 -05:00

Author

Owner

@louislam commented on GitHub (Jun 27, 2022):

I change it to feature-request, as it is an expected behavior and I think it is quite normal for relational database without live data.

@louislam commented on GitHub (Jun 27, 2022): I change it to `feature-request`, as it is an expected behavior and I think it is quite normal for relational database without live data.

deekerman commented

2026-02-28 02:13:48 -05:00

Author

Owner

@joe-eklund commented on GitHub (Jun 27, 2022):

I see. I disagree that it is normal for any database to behave in this way, but it is your project, so you definitely have final say on application behavior.

I have never encountered any other application that behaves this way, which is why I feel it's a bug. This behavior is pretty critical for the RESTful API I am developing to function correctly, so I hope that you consider changing this to reflect the expected behavior above.

Thanks!

@joe-eklund commented on GitHub (Jun 27, 2022): I see. I disagree that it is normal for any database to behave in this way, but it is your project, so you definitely have final say on application behavior. I have never encountered any other application that behaves this way, which is why I feel it's a bug. This behavior is pretty critical for the RESTful API I am developing to function correctly, so I hope that you consider changing this to reflect the expected behavior above. Thanks!

deekerman commented

2026-02-28 02:13:48 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 6, 2023):

Given the current architecture of Uptime Kuma I would classify this is a wontfix (read: not in scope) issue.
The reason behind this is that SQLite would require going to the C-API-level (I think should not be opening this pandoras box) and MariaDB would require even worse hacks.
=> Polling would be the only option
=> given how minor the feature is, this is not worth the very significant engineering effort required.

closing as not planned due to the rationale explained above (if a good argument is made why this is nessesary/.. we can reopen)

Instead of expecting that we look if somebody changed the database while we were not looking:

stop your instance before
make a backup
tamper with it
restart the instance

Alternatively (this is the actual path that I think this should be done with):

Use the unofffical https://pypi.org/project/uptime-kuma-api/
wait for #118 to be finally ready ^^

@CommanderStorm commented on GitHub (Dec 6, 2023): Given the current architecture of Uptime Kuma I would classify this is a `wontfix` (read: not in scope) issue. The reason behind this is that SQLite would require [going to the C-API-level](https://www.sqlite.org/c3ref/update_hook.html) (I think should not be opening this pandoras box) and MariaDB would require [even worse hacks](https://medium.com/@mohammedalrowad/monitoring-mysql-data-changes-in-real-time-via-nodejs-binary-logs-c379720c0333). => Polling would be the only option => given how minor the feature is, this is not worth the very significant engineering effort required. closing as not planned due to the rationale explained above (if a good argument is made why this is nessesary/.. we can reopen) Instead of expecting that we look if somebody changed the database while we were not looking: - stop your instance before - make a backup - tamper with it - restart the instance Alternatively (this is the actual path that I think this should be done with): - Use the unofffical https://pypi.org/project/uptime-kuma-api/ - wait for #118 to be finally ready ^^

deekerman referenced this issue

2026-02-28 02:15:33 -05:00

Scheduled Maintenance Windows (Pauses notifications & banner displays on Status Page) #1264

deekerman referenced this issue

2026-02-28 02:15:33 -05:00

Scheduled Maintenance Windows (Pauses notifications & banner displays on Status Page) #1264