Push type monitors doesn't receive `up` events

[Lanhild]

📑 I have found these related issues/pull requests

N/A

🛡️ Security Policy

• [X] I agree to have read this project Security Policy

Description

I have a push monitor that receives pings every 10 minutes. Whether the monitor should be down or up is determined by the status param sent by my cron.

Once a down event happens, the monitor never registers up events, unless another down happens.

👟 Reproduction steps

Have the following monitor (type push):

1. Send a down ping
2. Send an up ping - it does not register
3. Send another down ping
4. Send another up ping - this one will register

👀 Expected behavior

Up events should register, regardless of the previous ping event.

😓 Actual Behavior

Up events don't register properly

🐻 Uptime-Kuma Version

1.23.13

💻 Operating System and Arch

Ubuntu 22.04

🌐 Browser

Version 126.0.6478.55 (Official Build) (64-bit)

🖥️ Deployment Environment

• Runtime: Docker
• Database: sqlite
• Filesystem used to store the database on: btrfs, SSD
• number of monitors: 107

📝 Relevant log output

No response

[CommanderStorm]

I somewhat suspect that the code you are using to trigger the push monitor is a bit detective. Otherwise, why would it trigger DOWN - with message OK?

=> could you share the code you are using and/or what urls you are calling (with secrets redacted)

[Lanhild]

@CommanderStorm

My mistake, forgot to specify.

At the end of my cron logic, there's a condition that sends the ping to Uptime Kuma.

https://status/api/push/monitorId?status=up&msg=OK&ping=0ms, when UP. https://status/api/push/monitorId?status=down&msg=not responding&ping=0ms, when DOWN.

Otherwise, why would it trigger DOWN - with message OK?

The OK message was just the value I passed in the msg query parameter for testing.

[jotremb]

I'm having the exact same issue, and I can confirm that sending a "down" event followed by an "up" event does bring the state back to normal as you stated.

I'm actually running a PowerShell with Task Scheduler for my pushes and I'm able to recreate those conditions when pushing manually to the push URI.

I would add, that this issue seems to be present only when using "retries" > 0.