mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Push monitor retries not reset after a heartbeat is received #4574
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#4574
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 @jdfranel on GitHub (Jan 5, 2026).
📑 I have found these related issues/pull requests
None
🛡️ Security Policy
📝 Description
Hi there,
I recently migrated to v2.0.2, migration when nicely (took a long time but eventually finished without issues) and then I used kumadb-migrator to move data to a mariadb database. Everything seemed to work correctly and I let i run. Not sure it is related to my issue but I put it there just to have the whole picture.
The issue is, since v2.0.2, I have a couple of PUSH monitors that are monitoring a daily job. The heartbeat duration is set to 1 hour 25 retries. But event when an UP heartbeat is pushed the retries are still incrementing until the monitor goes DOWN.
Here is what it looks on the dashboard:

👟 Reproduction steps
👀 Expected behavior
Same behaviour that I had before v2. As soon as the UP heartbeat is pushed, the retry counter should be reset.
😓 Actual Behavior
The retry counter sometimes still keep counting event though an UP heartbeat is registered.
Here is the database extract where the heartbeat
27383803does not reset the retries counter.🐻 Uptime-Kuma Version
2.0.2
💻 Operating System and Arch
Debian 12
🌐 Browser
Brave 1.85.118 (Official Build) (64-bit)
🖥️ Deployment Environment
28.0.4(Buildb8034c0)2.34.011.8(LTS: Yes)118Docker compose file
📝 Relevant log output
@jdfranel commented on GitHub (Jan 9, 2026):
I think I found a workaround the issue. I edited the push monitors by:
The monitor is now in state PENDING after being UP as expected and the
retriesvalue is correctly reset. The change has been made between the heartbeat received27738691and27857003.I guess the root cause was that something was not migrated correctly when I went from SQLite to MariaDB, event though I couldn't find anything obvious in the
monitorstable definition.@jdfranel commented on GitHub (Jan 13, 2026):
Nevermind, the issue is still here. I didn't touche anything since I tried the workaround and the monitor juste turned DOWN le day after. Database show that the retries counter is still incrementing event though UP heartbeats have been received.