Healthchecks hook: Not working for non-success signals with run ID

[mvidelatraduc]

Describe the bug
Backrest has an apparently undocumented behavior where it appends Healthchecks non-success signals (/start, /fail, etc.) to the ping URL automatically for conditions such as CONDITION_SNAPSHOT_START or CONDITION_ANY_ERROR. (See: https://github.com/garethgeorge/backrest/blob/main/internal/hook/types/healthchecks.go)

This means that passing a run ID as a query parameter will create a badly-formed URL and make the hook fail:

error: sending healthchecks message to "https://hc-ping.com/<my-check-uuid>?rid=<my-run-id>/start": unexpected status 400: 400 Bad Request

running healthchecks hook plan/<my-plan>/hook/2 triggered by CONDITION_SNAPSHOT_START

A workaround is to use a command hook with something like curl <URL>.

Additionally, this append behavior might also conflict with the exit code functionality in Healthchecks for these conditions.

To Reproduce
Steps to reproduce the behavior:

1. Create a Healthchecks hook with a run ID query parameter for a non-success condition.
2. Run the hook.

Expected behavior
The hook should create a well-formed URL, either automatically or by making the user input the correct URL manually. An example for the /start signal:

Healthchecks UUID format:
https://hc-ping.com/<my-check-uuid>/start?rid=<my-run-id>
Healthchecks slug format:
https://hc-ping.com/<my-ping-id>/<my-slug>/start?rid=<my-run-id>

Additionally, it would be useful to alert the user not to append the signal to the URL, if it's going to be inserted automatically.

Platform Info

• OS and Architecture [Microsoft Windows Server 2025 Standard 10.0.26100 Build 26100]
• Backrest Version [1.7.2]

[garethgeorge]

Interesting report, it's definitely awkward that backrest is just concatenating and failing without nicely validating the URL.

I am curious to hear a bit more about the expected behavior of providing the run id as a query parameter? Wouldn't every backup be reporting to the same run ID? Does that behave as expected in healthchecks.io or would it be better for backrest's healthcheck integration to generate and set a new run ID each time it runs a backup? E.g. a random GUID I assume?

[mvidelatraduc]

Interesting report, it's definitely awkward that backrest is just concatenating and failing without nicely validating the URL.

I am curious to hear a bit more about the expected behavior of providing the run id as a query parameter? Wouldn't every backup be reporting to the same run ID? Does that behave as expected in healthchecks.io or would it be better for backrest's healthcheck integration to generate and set a new run ID each time it runs a backup? E.g. a random GUID I assume?

@garethgeorge Hi, Gareth, thanks for your prompt answer.

At least for my use case, I'm using specific run IDs to identify different Backrest plans/repositories. This means I can have a single healthcheck for a daily backup scheduled task, with run IDs identifying different repos. AFAIK, this is basically one of the intended uses of run IDs in Healthchecks: to create different logs and alerts for parallel or sequential subtasks within a scheduled task. A failure for one of the run IDs would still make the healthcheck fail while keeping the stats for the other repos separate.

In another more pragmatic angle, this also means that I don't have to create multiple healthchecks for multiple repos if they're all on the same schedule, given that Healthchecks.io charges money for more healthchecks.

[garethgeorge]

Thanks for elaborating, this makes sense to me. Fixed in https://github.com/garethgeorge/backrest/releases/tag/v1.8.0 .