starred/uptime-kuma

Fork 0

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

Some questions about the project and vision #2198

New issue

Closed

opened 2026-02-28 02:46:16 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-28 02:46:16 -05:00

Owner

Originally created by @capttrousers on GitHub (May 20, 2023).

⚠️ 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

📝 Describe your problem

I've been using Uptime Kuma for a week to monitor some docker containers and svcs on my raspberry pis, it's working great, really well done project.

I've been diving into the source code a bit and have some questions:

What is the intended use cases/how to guides for plugins? I see the plugins dir created in the data_dir but not sure how to go about creating one, or what I could do with that.
For Push based monitors, what's the intended usage of the PING param? I've been using it for tracking the duration of certain api calls in a batch service, and putting different msg's for each task in the batch job but I'm thinking there might be a discussion to be had about this kind of pure metric monitoring. Would love to chat more about this part.
For Push based monitors, it looks like the Duration prop is calculated by the datediff between current and last push event? I dont quite understand how that plays with the heartbeat check interval that's set for Push based monitors. Is the check interval for Push monitors just basically defining the window that you'd expect to receive at least one push event?
For the Details page for a monitor, what are your thoughts on allowing a "show all" toggle, to show all events, not just the important heartbeats?
On the Details page, what's the distinction between clearing Events vs Heartbeats? Looking at the source code, it seems like clearing events just nulls out the properties but keeps the records, whereas clear Heartbeats deletes the records? Not clear what the first one would be used for?
I saw the Project roadmap page shows supporting Mysql/Mariadb in addition to sqlite, I saw the redbean library also supports those rdbms options, so is that a difficult lift? If not, I'd be willing to try to tackle that over the next few weeks. One use case I'd like to try to support, possibly with plugins, is defining some custom charts for various metrics and embedding them in the Details pane or maybe a top level Status page. There are a few charting services I'm planning to checkout: Superset or Perses, but Im not clear on the path forward here yet. But having the db be connectable like mariadb would be great to help test something like that out.

Thanks again for all your work on this, it's really impressive.

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.21.3

💻 Operating System and Arch

rasbian bullseye, but running uptime-kuma via docker

🌐 Browser

Firefox 108

🐋 Docker Version

Client: Docker Engine - Community Version: 23.0.4 API version: 1.42 Go version: go1.19.8 Git commit: f480fb1 Built: Fri Apr 14 10:32:04 2023 OS/Arch: linux/arm Context: default Server: Docker Engine - Community Engine: Version: 23.0.4 API version: 1.42 (minimum version 1.12) Go version: go1.19.8 Git commit: cbce331 Built: Fri Apr 14 10:32:04 2023 OS/Arch: linux/arm Experimental: false containerd: Version: 1.6.20 GitCommit: 2806fc1057397dbaeefbea0e4e17bddfbd388f38 runc: Version: 1.1.5 GitCommit: v1.1.5-0-gf19387a docker-init: Version: 0.19.0 GitCommit: de40ad0

🟩 NodeJS Version

No response

Originally created by @capttrousers on GitHub (May 20, 2023). ### ⚠️ 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) ### 📝 Describe your problem I've been using Uptime Kuma for a week to monitor some docker containers and svcs on my raspberry pis, it's working great, really well done project. I've been diving into the source code a bit and have some questions: - What is the intended use cases/how to guides for plugins? I see the `plugins` dir created in the data_dir but not sure how to go about creating one, or what I could do with that. - For Push based monitors, what's the intended usage of the PING param? I've been using it for tracking the duration of certain api calls in a batch service, and putting different msg's for each task in the batch job but I'm thinking there might be a discussion to be had about this kind of pure metric monitoring. Would love to chat more about this part. - For Push based monitors, it looks like the Duration prop is calculated by the datediff between current and last push event? I dont quite understand how that plays with the heartbeat check interval that's set for Push based monitors. Is the check interval for Push monitors just basically defining the window that you'd expect to receive at least one push event? - For the Details page for a monitor, what are your thoughts on allowing a "show all" toggle, to show all events, not just the important heartbeats? - On the Details page, what's the distinction between clearing Events vs Heartbeats? Looking at the source code, it seems like clearing events just nulls out the properties but keeps the records, whereas clear Heartbeats deletes the records? Not clear what the first one would be used for? - I saw the Project roadmap page shows supporting Mysql/Mariadb in addition to sqlite, I saw the redbean library also supports those rdbms options, so is that a difficult lift? If not, I'd be willing to try to tackle that over the next few weeks. One use case I'd like to try to support, possibly with plugins, is defining some custom charts for various metrics and embedding them in the Details pane or maybe a top level Status page. There are a few charting services I'm planning to checkout: Superset or Perses, but Im not clear on the path forward here yet. But having the db be connectable like mariadb would be great to help test something like that out. Thanks again for all your work on this, it's really impressive. ### 📝 Error Message(s) or Log _No response_ ### 🐻 Uptime-Kuma Version 1.21.3 ### 💻 Operating System and Arch rasbian bullseye, but running uptime-kuma via docker ### 🌐 Browser Firefox 108 ### 🐋 Docker Version Client: Docker Engine - Community Version: 23.0.4 API version: 1.42 Go version: go1.19.8 Git commit: f480fb1 Built: Fri Apr 14 10:32:04 2023 OS/Arch: linux/arm Context: default Server: Docker Engine - Community Engine: Version: 23.0.4 API version: 1.42 (minimum version 1.12) Go version: go1.19.8 Git commit: cbce331 Built: Fri Apr 14 10:32:04 2023 OS/Arch: linux/arm Experimental: false containerd: Version: 1.6.20 GitCommit: 2806fc1057397dbaeefbea0e4e17bddfbd388f38 runc: Version: 1.1.5 GitCommit: v1.1.5-0-gf19387a docker-init: Version: 0.19.0 GitCommit: de40ad0 ### 🟩 NodeJS Version _No response_

deekerman

2026-02-28 02:46:16 -05:00

closed this issue
added the
Stale

help
labels

deekerman commented

2026-02-28 02:46:22 -05:00

Author

Owner

@capttrousers commented on GitHub (May 20, 2023):

Some other Qs I forgot to add:

what is the purpose of this line
I've seen some feature requests about monitoring other system things like cpu/memory/disk space. There's a nice simple tool called glances That I've tested for this use case but uptime-kuma is much nicer to look at it, so curious what your thoughts are on supporting something like that, to consolidate more monitoring within the single tool? Maybe this is another good use case for the plugins system? But I couldnt find docs on the plugins. Or even monitoring memory/CPU usage of docker containers with monitors?

@capttrousers commented on GitHub (May 20, 2023): Some other Qs I forgot to add: - what is the purpose of [this line](https://github.com/louislam/uptime-kuma/blob/1e1cc86a1095e78010dc6810997de08ec42700ff/server/check-version.js#L61) - I've seen some feature requests about monitoring other system things like cpu/memory/disk space. There's a nice simple tool called [glances](https://nicolargo.github.io/glances/) That I've tested for this use case but uptime-kuma is much nicer to look at it, so curious what your thoughts are on supporting something like that, to consolidate more monitoring within the single tool? Maybe this is another good use case for the plugins system? But I couldnt find docs on the plugins. Or even monitoring memory/CPU usage of docker containers with monitors?

deekerman commented

2026-02-28 02:46:22 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 20, 2023):

These are a lot of questions for one issue. I tried to answer them as much as I can.

On the topic of plugins:

There are multiple proposals in issues. Until now there has been #1787
This is a feature in the ideas section of the Roadmap.
I don't quite know what Louis vision is on this topic, but one plugin is available at https://uptime.kuma.pet/c/plugins.json

Push-based monitors

I am not qualifed to answer this question.

"show all"

This does not fit in the help section. Please open another issue in the correct section.

clearing events vs heartbeats

Heartbeats include more metadata (f.ex. ping-duration) which you might not want to delete. There are however cases where an event happened after you want a clean slate (f.ex. a lot of DNS errors after adding too many monitors without the caching enabled).

database

I don't understand what you mean.
See #1139 for the current status of mariadb.

what is the purpose of this line

This line does not have any value afaik. A PR to remove it would be appreciated.

monitoring system usage

I think this would not be a good use case for an uptime monitor. (maybe a plugin?)
I think there are better tools for this (namely the Grafana stack or other promising contenders in the observability space)
This could be an expansion goal, but currently there would need to be a lot of work.

@CommanderStorm commented on GitHub (May 20, 2023): These are a lot of questions for one issue. I tried to answer them as much as I can. # On the topic of **plugins**: There are multiple proposals in issues. Until now there has been #1787 This is a feature in the [ideas section of the Roadmap](https://github.com/users/louislam/projects/4/views/1). I don't quite know what Louis vision is on this topic, but one plugin is available at https://uptime.kuma.pet/c/plugins.json # Push-based monitors I am not qualifed to answer this question. # "show all" This does not fit in the help section. Please [open another issue in the correct section](https://github.com/louislam/uptime-kuma/issues/new?assignees=&labels=feature-request&projects=&template=feature_request.yaml). # clearing events vs heartbeats Heartbeats include more metadata (f.ex. ping-duration) which you might not want to delete. There are however cases where an event happened after you want a clean slate (f.ex. a lot of DNS errors after adding too many monitors without the caching enabled). # database I don't understand what you mean. See #1139 for the current status of mariadb. # what is the purpose of [this line](https://github.com/louislam/uptime-kuma/blob/1e1cc86a1095e78010dc6810997de08ec42700ff/server/check-version.js#L61) This line does not have any value afaik. A PR to remove it would be appreciated. # monitoring system usage I think this would not be a good use case for an uptime monitor. (maybe a plugin?) I think there are better tools for this (namely the Grafana stack or other promising contenders in the observability space) This could be an expansion goal, but currently there would need to be a lot of work.

deekerman commented

2026-02-28 02:46:22 -05:00

Author

Owner

@chakflying commented on GitHub (May 21, 2023):

Regarding how push monitors work, you can read about the logic of operation here: #1428. Your basic understanding is correct.

@chakflying commented on GitHub (May 21, 2023): Regarding how push monitors work, you can read about the logic of operation here: #1428. Your basic understanding is correct.

deekerman commented

2026-02-28 02:46:22 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Aug 19, 2023):

We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.

@github-actions[bot] commented on GitHub (Aug 19, 2023): We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.

deekerman commented

2026-02-28 02:46:22 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Aug 21, 2023):

This issue was closed because it has been stalled for 2 days with no activity.

@github-actions[bot] commented on GitHub (Aug 21, 2023): This issue was closed because it has been stalled for 2 days with no activity.