mirror of
https://github.com/healthchecks/healthchecks.git
synced 2026-04-25 15:05:49 +03:00
[GH-ISSUE #1160] Cron going down before they are supposed to #800
Labels
No labels
bug
bug
bug
feature
good-first-issue
new integration
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/healthchecks#800
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 @shaqaruden on GitHub (May 20, 2025).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1160
I have some cron jobs that don't run often (Weekly, and monthly). I have a one hour grace period set on them all. It seems that for these they will down before the next cron configured schedule as lapsed.
For example I have this one cron that runs monthly, configured as so
Looking at the events I see it ping then go down 5 hours later
I verified that my cron job was setup correctly
Is this expected behavior or is this a bug?
@cuu508 commented on GitHub (May 20, 2025):
According to the configured schedule, Healthchecks expects a ping at or after 10:00. There is no ping between 10:00 and 11:00, so at 11:00 grace time runs out and the check's status changes to "down".
The ping at 6:04 does not count, because it arrived too early, before 10:00.
@shaqaruden commented on GitHub (May 20, 2025):
I overlooked that detail, thank you for pointing that out. The issue is the timezone in my Healthchecks container is not correct then, correct?
@cuu508 commented on GitHub (May 22, 2025):
The timezone of Healthchecks container should not matter (unless you are doing wonky things like mounting over /etc/localtime). I would check the following:
@shaqaruden commented on GitHub (May 23, 2025):
The timezone on the system sending the ping is correct and it's time matches the time on the server. Yes the cron schedule is 0 10 15 * *
@cuu508 commented on GitHub (May 24, 2025):
datecommand) in the Healthchecks container right now?datecommand) on the client system right now?journalctl --since "2025-05-15" -t CRONon the client system?Please answer every question fully (instead of answering just the ones you think are relevant). Please edit out any sensitive information.
@shaqaruden commented on GitHub (May 27, 2025):
Timezone of Healthchecks container (After updating timezone of container)
EDT
Healthchecks Image
healthchecks/healthchecks:latest
Dockerfile (Set Timezone(New after creating issue))
Timezone of client
EDT
Local time of Healthchecks

Local time of client

content of crontab
Ping test

Journalctl output
No output to provide as client is a docker container and does not have journalctl installed
Here is an additional screenshot of the healthcheck I used for the test. As you can see it's previous ping from the client had the same effect of going down. This one does not quite make as much sense it is suppose to go off a 3AM every Monday but Healthchecks shows the same 11PM ping
@cuu508 commented on GitHub (May 29, 2025):
Thanks for the additional information and sorry for the delay getting back to you.
In the 9th step (ping test), Healthchecks shows the local time as 14:46. Was that the expected value, i.e. was the wall clock time indeed 14:46 at the time of ping? Or was the displayed time also 4 hours off?
If the timestamps look correct when pinging manually, but are 4 hours off for events triggered by cron, then the next step would be to verify if cron runs jobs at the right time.
One idea on how to test this, if feasible, would be to add another cron job:
It runs every minute and grabs the Date response header from google.com, and submits it in POST body to the Healthchecks instance. After it has run a couple times, take a look at the ping details dialog and see if the UTC time matches up with the timestamp in the ping's body.
@shaqaruden commented on GitHub (May 29, 2025):
I can definitely do that. I will add that cron tomorrow morning
@shaqaruden commented on GitHub (May 30, 2025):
Here is a screenshot of a ping from that cron
@cuu508 commented on GitHub (May 30, 2025):
Thanks. This looks as expected, the time in google's "Date:" header matches the UTC time of the ping.
Can you do another experiment? Add a job that should run 5 minutes in the future. If the current time is 12:34, add a job
Then, after 12:39, see if a ping was sent, and whether its timestamp is 12:39 EDT (16:39 UTC).
The idea with this is to check if the cron daemon runs the job at the correct time.
@cuu508 commented on GitHub (Jun 13, 2025):
No response, closing.