Change logging to warning or error #672

Closed
opened 2026-02-28 01:54:09 -05:00 by deekerman · 8 comments
Owner

Originally created by @agneevX on GitHub (Dec 17, 2021).

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

  • I checked and didn't find similar issue

🛡️ Security Policy

📝 Describe your problem

Uptime-kuma writes a new line to stdout for each measurement.

This makes very frequent writes.

Would be nice to set log levels to either of DEBUG, INFO, WARN or ERROR, if that's not already possible.

🐻 Uptime-Kuma Version

💻 Operating System and Arch

🌐 Browser

🐋 Docker Version

No response

🟩 NodeJS Version

No response

Originally created by @agneevX on GitHub (Dec 17, 2021). ### ⚠️ 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 Uptime-kuma writes a new line to stdout for each measurement. This makes very frequent writes. Would be nice to set log levels to either of `DEBUG`, `INFO`, `WARN` or `ERROR`, if that's not already possible. ### 🐻 Uptime-Kuma Version - ### 💻 Operating System and Arch - ### 🌐 Browser - ### 🐋 Docker Version _No response_ ### 🟩 NodeJS Version _No response_
deekerman 2026-02-28 01:54:09 -05:00
  • closed this issue
  • added the
    Stale
    help
    labels
Author
Owner

@ivanbratovic commented on GitHub (Dec 17, 2021):

This is related to a currently open PR #910

@ivanbratovic commented on GitHub (Dec 17, 2021): This is related to a currently open PR #910
Author
Owner

@twiesing commented on GitHub (May 29, 2022):

Any news on this @ivanbratovic @louislam?

Especially on devices like Raspberry Pi it would be nice to have as few write accesses as possible. However, the logs become significantly large with many monitors due to the log level. It would be nice if this could be configured via environment variables.

@twiesing commented on GitHub (May 29, 2022): Any news on this @ivanbratovic @louislam? Especially on devices like Raspberry Pi it would be nice to have as few write accesses as possible. However, the logs become significantly large with many monitors due to the log level. It would be nice if this could be configured via environment variables.
Author
Owner

@flok commented on GitHub (May 30, 2022):

Any news on this @ivanbratovic @louislam?

Especially on devices like Raspberry Pi it would be nice to have as few write accesses as possible. However, the logs become significantly large with many monitors due to the log level. It would be nice if this could be configured via environment variables.

if you want an easy fix just add the environment variable to the docker

UPTIME_KUMA_HIDE_LOG=debug_monitor,info_monitor

This disables the INFO log for the Successful Response

@flok commented on GitHub (May 30, 2022): > Any news on this @ivanbratovic @louislam? > > Especially on devices like Raspberry Pi it would be nice to have as few write accesses as possible. However, the logs become significantly large with many monitors due to the log level. It would be nice if this could be configured via environment variables. if you want an easy fix just add the environment variable to the docker `UPTIME_KUMA_HIDE_LOG=debug_monitor,info_monitor` This disables the INFO log for the Successful Response
Author
Owner

@twiesing commented on GitHub (May 30, 2022):

Very nice! Thank you. Are there any docs about the env?

@twiesing commented on GitHub (May 30, 2022): Very nice! Thank you. Are there any docs about the env?
Author
Owner

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

Very nice! Thank you. Are there any docs about the env?

It can be found in the wiki.

I also noticed that the log is large, because it includes datetime and maybe too detailed. I am thinking whether disabling it or showing less info.

@louislam commented on GitHub (Jun 1, 2022): > Very nice! Thank you. Are there any docs about the env? It can be found in the wiki. I also noticed that the log is large, because it includes datetime and maybe too detailed. I am thinking whether disabling it or showing less info.
Author
Owner

@twiesing commented on GitHub (Jun 1, 2022):

Very nice! Thank you. Are there any docs about the env?

It can be found in the wiki.

I also noticed that the log is large, because it includes datetime and maybe too detailed. I am thinking whether disabling it or showing less info.

Thanks, good to know! Very nice project btw.

@twiesing commented on GitHub (Jun 1, 2022): > > Very nice! Thank you. Are there any docs about the env? > > It can be found in the wiki. > > I also noticed that the log is large, because it includes datetime and maybe too detailed. I am thinking whether disabling it or showing less info. Thanks, good to know! Very nice project btw.
Author
Owner

@github-actions[bot] commented on GitHub (Sep 23, 2022):

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 (Sep 23, 2022): 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.
Author
Owner

@github-actions[bot] commented on GitHub (Sep 25, 2022):

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

@github-actions[bot] commented on GitHub (Sep 25, 2022): This issue was closed because it has been stalled for 2 days with no activity.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uptime-kuma#672
No description provided.