mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
clean cache files automatically after a certain (non-configurable) size #4027
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#4027
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Justinzobel on GitHub (Mar 12, 2025).
⚠️ Please verify that this question has NOT been raised before.
🛡️ Security Policy
📝 Describe your problem
I think we need an entry in the wiki for maintenance of uptime kuma.
For example I found in ~/.cache/Cypress 1.2GB of files, are they needed? Can they be cleaned up?
Is there a way to clean up unused npm modules to save disk space?
I found a file
core.809(180MB) in my uptime-kuma folder, I assume it is a coredump from a crash. Can we clean these up regularly?📝 Error Message(s) or Log
No response
🐻 Uptime-Kuma Version
1.23.16
💻 Operating System and Arch
Ubuntu 24.04 x86_64
🌐 Browser
N/A
🖥️ Deployment Environment
@CommanderStorm commented on GitHub (Mar 25, 2025):
If there are general maintenance tasks, we should perform them not some entry in the wiki.
We tried to compress the npm part, but were not succssfull.
About the other part I don't know => reclassifying as a FR
@CommanderStorm commented on GitHub (Mar 25, 2025):
The coredump should not be deleted, instead it might contain important information why your system crashed (or not, who knows?)
=> consider looking at the crashdump and reporting the results
@Justinzobel commented on GitHub (Mar 25, 2025):
All the better if Uptime Kuma can clean up cache data by itself!
@Justinzobel commented on GitHub (Mar 25, 2025):
How does one open the crashdump file? Or is it easier if I just upload it somewhere for you to look at?
@CommanderStorm commented on GitHub (Mar 27, 2025):
Here is a stackexchange article explaining the various options:
https://askubuntu.com/questions/434431/how-can-i-read-a-crash-file-from-var-crash
I would ask you to do the work involved. Ther might be secrets in there you might not want shared/known.
@JEFFIN4144 commented on GitHub (Sep 26, 2025):
hey im interested