Push based monitoring issue/question #1367

Closed
opened 2026-02-28 02:18:48 -05:00 by deekerman · 1 comment
Owner

Originally created by @crypticviper on GitHub (Sep 7, 2022).

Hello,

Thank you for your great work on this project. Found it extremely useful for setting up my monitoring dashboard. I had some questions/doubts regarding the setting up of the "Push" monitoring type. I couldn't find much info on this on the internet either so asking here (so this is not necessarily an issue).

Below is my monitor configuration

Type: Push
Push URL: https://mydomain/api/push/xxxxxxxxxx?status=up&msg=OK&ping=
Heartbeat Interval: 600
Retries: 0
Heartbeat Retry Interval: 600

I am then using this push URL in docker health check as below:

.....
healthcheck:
test: wget --tries=1 https://mydomain/api/push/xxxxxxxxxx?status=up&msg=OK&ping= || exit 1
interval: 600s
start_period: 5s
timeout: 10s
.....

This setup works fine. However, I frequently get indicators saying a service is down with an error message as follows (below is the log from uptime kuma docker container)

2022-09-07T07:52:47.180Z [MONITOR] WARN: Monitor #24 'My Test Service': Failing: No heartbeat in the time window | Interval: 600 seconds | Type: push | Down Count: 0 | Resend Interval: 0

However, if I check logs of the service health check it seems to have no issues calling the push endpoint. See below log (check timestamps - looks like uptime kuma error is reported a few milliseconds before the request was actually completed on the service container?). BTW, the timestamp in uptime kuma is in UTC while on service container is in my timezone.

_{
  "Start": "2022-09-07T09:52:46.20662953+02:00",
  "End": "2022-09-07T09:52:47.368339627+02:00",
  "ExitCode": 0,
  "Output": "wget: can't open '25hiCQzTH5?status=up': File exists\n"
}_

One additional question:

Is this the right way to use the push monitoring mechanism? I didn't find any examples of using this so was just testing it this way.

Originally created by @crypticviper on GitHub (Sep 7, 2022). Hello, Thank you for your great work on this project. Found it extremely useful for setting up my monitoring dashboard. I had some questions/doubts regarding the setting up of the "Push" monitoring type. I couldn't find much info on this on the internet either so asking here (so this is not necessarily an issue). Below is my monitor configuration Type: Push Push URL: https://mydomain/api/push/xxxxxxxxxx?status=up&msg=OK&ping= Heartbeat Interval: 600 Retries: 0 Heartbeat Retry Interval: 600 I am then using this push URL in docker health check as below: ..... healthcheck: test: wget --tries=1 https://mydomain/api/push/xxxxxxxxxx?status=up&msg=OK&ping= || exit 1 interval: 600s start_period: 5s timeout: 10s ..... This setup works fine. However, I frequently get indicators saying a service is down with an error message as follows (below is the log from uptime kuma docker container) _2022-09-07T07:52:47.180Z [MONITOR] WARN: Monitor #24 'My Test Service': Failing: No heartbeat in the time window | Interval: 600 seconds | Type: push | Down Count: 0 | Resend Interval: 0_ However, if I check logs of the service health check it seems to have no issues calling the push endpoint. See below log (check timestamps - looks like uptime kuma error is reported a few milliseconds before the request was actually completed on the service container?). BTW, the timestamp in uptime kuma is in UTC while on service container is in my timezone. _{ "Start": "2022-09-07T09:52:46.20662953+02:00", "End": "2022-09-07T09:52:47.368339627+02:00", "ExitCode": 0, "Output": "wget: can't open '25hiCQzTH5?status=up': File exists\n" }_ One additional question: Is this the right way to use the push monitoring mechanism? I didn't find any examples of using this so was just testing it this way.
deekerman 2026-02-28 02:18:48 -05:00
Author
Owner

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

@crypticviper: Hello! 👋

This issue is being automatically closed because it does not follow the issue template. Please DO NOT open a blank issue.

@github-actions[bot] commented on GitHub (Sep 7, 2022): @crypticviper: Hello! :wave: This issue is being automatically closed because it does not follow the issue template. Please DO NOT open a blank issue.
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#1367
No description provided.