[GH-ISSUE #644] Execution time of script not shown in log page #466

New issue

Closed

opened 2026-02-25 23:42:34 +03:00 by kerem · 4 comments

kerem commented

2026-02-25 23:42:34 +03:00

Owner

Originally created by @jsddsfoh on GitHub (Apr 29, 2022).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/644

Hello,

I use /start and /stop for time measurement. It all works fine, but in the log the duration is not displayed for an entry, which execution time was about 2.5 days.
All other entries range from a few minutes to 8hrs and are displayed fine.

Originally created by @jsddsfoh on GitHub (Apr 29, 2022). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/644 Hello, I use /start and /stop for time measurement. It all works fine, but in the log the duration is not displayed for an entry, which execution time was about 2.5 days. All other entries range from a few minutes to 8hrs and are displayed fine.

kerem closed this issue

2026-02-25 23:42:34 +03:00

kerem commented

2026-02-25 23:42:34 +03:00

Author

Owner

@cuu508 commented on GitHub (Apr 29, 2022):

If the "start" and "complete" events are more than 24 hours apart, Healthchecks assumes they are not related.
The 24 hour threshold is defined here in the code: github.com/healthchecks/healthchecks@98f2536825/hc/api/models.py (L36)

This has been brought up a couple times before, perhaps it makes sense to increase the threshold to 48 or 72 hours.

@cuu508 commented on GitHub (Apr 29, 2022): If the "start" and "complete" events are more than 24 hours apart, Healthchecks assumes they are not related. The 24 hour threshold is defined here in the code: https://github.com/healthchecks/healthchecks/blob/98f2536825f13fc043a0623add7be1429fa7e5b3/hc/api/models.py#L36 This has been brought up a couple times before, perhaps it makes sense to increase the threshold to 48 or 72 hours.

kerem commented

2026-02-25 23:42:34 +03:00

Author

Owner

@jsddsfoh commented on GitHub (Apr 29, 2022):

I see, thanks for the response!
It's possible to set grace time and period up to 365days. I was wondering which script needs to run this long, but I'm sure there is somebody out there :D
So is there no way to make it possible to show the runtime? Maybe an alive-ping after a certain time? Or just remove the limit, but I assume it's there for a reason?

@jsddsfoh commented on GitHub (Apr 29, 2022): I see, thanks for the response! It's possible to set grace time and period up to 365days. I was wondering which script needs to run this long, but I'm sure there is somebody out there :D So is there no way to make it possible to show the runtime? Maybe an alive-ping after a certain time? Or just remove the limit, but I assume it's there for a reason?

kerem commented

2026-02-25 23:42:34 +03:00

Author

Owner

@cuu508 commented on GitHub (May 2, 2022):

Period: yes, there are jobs that run only once a month, once every 3 months, or less frequently. For grace time, I'm not sure there's an use case for months-long grace time. But I wanted the Period and Grace Time sliders to look symmetric.

Or just remove the limit, but I assume it's there for a reason?

Two reasons:

If a "start" and "success" signals are very far apart, there's a good chance they are not actually related. For example, let's say a job is scheduled to run once a week, and normally completes in 20 minutes. The job sends a /start signal and then crashes. Five days later, somebody gets around to investigating what happened to the job. During investigation, they manually send a "success" ping. The UI now shows the last duration as "5 days".
With longer durations, it's harder to fit the information on the screen. You could have durations like "3 days 23 h 59 min 49 sec". This can be tested and tuned (don't show seconds for long durations etc.), but takes more work ;-)

@cuu508 commented on GitHub (May 2, 2022): Period: yes, there are jobs that run only once a month, once every 3 months, or less frequently. For grace time, I'm not sure there's an use case for months-long grace time. But I wanted the Period and Grace Time sliders to look symmetric. > Or just remove the limit, but I assume it's there for a reason? Two reasons: * If a "start" and "success" signals are very far apart, there's a good chance they are not actually related. For example, let's say a job is scheduled to run once a week, and normally completes in 20 minutes. The job sends a `/start` signal and then crashes. Five days later, somebody gets around to investigating what happened to the job. During investigation, they manually send a "success" ping. The UI now shows the last duration as "5 days". * With longer durations, it's harder to fit the information on the screen. You could have durations like "3 days 23 h 59 min 49 sec". This can be tested and tuned (don't show seconds for long durations etc.), but takes more work ;-)

kerem commented

2026-02-25 23:42:34 +03:00

Author

Owner

@jsddsfoh commented on GitHub (May 2, 2022):

Thanks for setting it to 72h! This should fit at least my needs most of the time.

Maybe it's possible to have MAX_DELTA editable in config file in the future?

@jsddsfoh commented on GitHub (May 2, 2022): Thanks for setting it to 72h! This should fit at least my needs most of the time. Maybe it's possible to have MAX_DELTA editable in config file in the future?