[GH-ISSUE #1252] Mark tests as resolved #843

New issue

Closed

opened 2026-02-25 23:43:46 +03:00 by kerem · 1 comment

kerem commented

2026-02-25 23:43:46 +03:00

Owner

Originally created by @DarkWiiPlayer on GitHub (Jan 7, 2026).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1252

In practice, fixing a job that is down won't always mean it immediately runs again. There is currently no good way of handling this:

Pausing the test means it won't send a new down-notification if the next scheduled run fails quietly
Leaving it as "Down" additionally leads to alarm fatigue
Manually pinging the end-point "fakes" a run that could be misleading to other users

Would it be possible to add an option to mark a failed test as resolved, which puts it in a similar state to "new", where it shows in more neutral colours while still being expected to be working for its next scheduled run?

Originally created by @DarkWiiPlayer on GitHub (Jan 7, 2026). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1252 In practice, fixing a job that is down won't always mean it immediately runs again. There is currently no good way of handling this: - Pausing the test means it won't send a new down-notification if the next scheduled run fails quietly - Leaving it as "Down" additionally leads to alarm fatigue - Manually pinging the end-point "fakes" a run that could be misleading to other users Would it be possible to add an option to mark a failed test as resolved, which puts it in a similar state to "new", where it shows in more neutral colours while still being expected to be working for its next scheduled run?

kerem closed this issue

2026-02-25 23:43:46 +03:00

kerem commented

2026-02-25 23:43:47 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 7, 2026):

When I've fixed the job but don't want to wait for it to run again, I manually ping it myself.

Manually pinging the end-point "fakes" a run that could be misleading to other users

In the event log, the manual ping can be recognized by the client's IP address and User-Agent string, and perhaps by the datetime that does not fit the schedule. Why do you think it would be misleading?

@cuu508 commented on GitHub (Jan 7, 2026): When I've fixed the job but don't want to wait for it to run again, I manually ping it myself. > Manually pinging the end-point "fakes" a run that could be misleading to other users In the event log, the manual ping can be recognized by the client's IP address and User-Agent string, and perhaps by the datetime that does not fit the schedule. Why do you think it would be misleading?