Monitor stucks at PENDING

[karelkryda]

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

Description

Today I had an outage on two services that I monitor. Both services were stuck in the PENDING state and did not go to the DOWN state. Truth be told, both services are of the PUSH type. Unfortunately (thankfully) I didn't have an outage on another type of monitor, so I can't say if it's just PUSH.

👟 Reproduction steps

• Create a push monitor
• Visit URL to make push online
• Leave the push without activity

👀 Expected behavior

The monitor should go down after 3 failed attempts

😓 Actual Behavior

Monitor remains in pending state

🐻 Uptime-Kuma Version

1.12.1

💻 Operating System and Arch

Debian 11

🌐 Browser

Latest Google Chrome

🐋 Docker Version

20.10.12

🟩 NodeJS Version

No response

📝 Relevant log output

No response

[TimothyGillespie]

This ticket is closed but related. I have the same issue.

https://github.com/louislam/uptime-kuma/issues/922

[karelkryda]

@TimothyGillespie I'm not sure if this is exactly the same issue, but ok.

[DPerkunas]

I don't consider this related to Timothy's. I have same issue. Fresh install. Status shows pending for the monitor, rather than up or down. Nothing to do with notifications.

Edit: In my case, it was internal firewall rules blocking the request in a strange way. Figured one out, trying to figure out another. Basically, confirm you can "wget ipaddress/url" from within the Kuma server. If you can't, got a network issue to figure out.

Or in your case, see if you can make a push request(?) manually from within Kuma server. I don't know how to do that, but you probably will.

[chakflying]

I can confidently say this was fixed with #1627 and #1428.

Back then, the push code looks like this:

                } else if (this.type === "push") {      // Type: Push
                    const time = R.isoDateTime(dayjs.utc().subtract(this.interval, "second"));

                    let heartbeatCount = await R.count("heartbeat", " monitor_id = ? AND time > ? ", [
                        this.id,
                        time
                    ]);

                    debug("heartbeatCount" + heartbeatCount + " " + time);

                    if (heartbeatCount <= 0) {
                        // Fix #922, since previous heartbeat could be inserted by api, it should get from database
                        previousBeat = await Monitor.getPreviousHeartbeat(this.id);

                        throw new Error("No heartbeat in the time window");
                    } else {
                        // No need to insert successful heartbeat for push type, so end here
                        retries = 0;
                        this.heartbeatInterval = setTimeout(beat, beatInterval * 1000);
                        return;
                    }

heartbeatCount only looks for heartbeats since the last regular interval, and doesn't consider retries. The result is that it counted the last PENDING beat, goes to the else branch and retries keep getting reset to 0.

[CommanderStorm]

@chakflying you are missing a call to action in your descriptions:

@karelkryda (only you or Louis can close issues 😉) I believe this issue has been resolved and you can safely close this issue. The fix for this issue is available after 1.16.1

[chakflying]

Alright, I will try to include that and copy your template if you don't mind ;)

[karelkryda]

You're probably right. I'm not aware of having dealt with anything like this recently. I'm closing this issue.

[siimots]

In latest version (1.23.3) also many of my services were down but Uptime Kuma stayed "Pending" state for 12 hours and did not send out alerts.

Maybe send alerts also out if "Pending" is more than 60 minutes?

[chakflying]

You should open a new issue with detailed debugging information, since the original issue is already fixed.