starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-25 06:55:53 +03:00

[GH-ISSUE #849] Revert API-breaking changes. #597

New issue

Closed

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

kerem commented

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

Owner

Originally created by @mtesch-um on GitHub (Jun 23, 2023).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/849

The API was changed in a non-backward compatible way with the recent changes to auto-create slugs. The documentation hasn't even been updated to match the new API.

We're paying customers and want a stable API.

Would you be able to revert the changes to the auto-creation?

The current documentation, upon which we rely:

Originally created by @mtesch-um on GitHub (Jun 23, 2023). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/849 The API was changed in a non-backward compatible way with the recent changes to auto-create slugs. The documentation hasn't even been updated to match the new API. We're paying customers and want a stable API. Would you be able to revert the changes to the auto-creation? The current documentation, upon which we rely: <img width="805" alt="image" src="https://github.com/healthchecks/healthchecks/assets/60145479/07b4f5e1-c60e-4f1d-97b1-1977a4eb5b06">

kerem closed this issue

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

kerem commented

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

Author

Owner

@mtesch-um commented on GitHub (Jun 23, 2023):

Suggest making auto-creation of slugs an opt-in feature that wont break code that relies on getting a 404 for a non-existent slug.

@mtesch-um commented on GitHub (Jun 23, 2023): Suggest making auto-creation of slugs an opt-in feature that wont break code that relies on getting a 404 for a non-existent slug.

kerem commented

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

Author

Owner

@cuu508 commented on GitHub (Jun 26, 2023):

You are right, I made a backwards-incompatible behavior change regarding the handing of non-existent slugs. Before the change, pinging a non-existent slug returned HTTP 404. After the change, Healthchecks auto-provisions the check and returns HTTP 200. I should have been more careful about rolling out this change, and I am sorry for the disruption.

Suggest making auto-creation of slugs an opt-in feature that wont break code that relies on getting a 404 for a non-existent slug.

Long-term, I want auto-provisioning be the default, and, ideally, the only mode.

I'm assuming your use case is (please correct me if I'm wrong):

ping a slug
if the ping request returns 404, assume the check does not exist, and create and configure it using Management API

And the problem with auto-provisioning and the 200 responses is, you now cannot easily detect if a check was just created and needs to be configured. If that's the case, I have a couple of ideas:

Improve the auto-provisioning code to return HTTP 201 instead of HTTP 200 if a check was just created. This would allow you to detect if a check was just created. Instead of checking for 404, you would check for 201. I can implement this relatively quickly.
I'm considering adding ability to configure some aspects of the check when auto-provisioning it like so:
```
curl https://hc-ping.com/<ping-key>/<slug>?timeout=300&grace=600
```
Perhaps there should also be a way to say "and please do not assign any channels to it":
```
curl https://hc-ping.com/<ping-key>/<slug>?timeout=300&grace=600&channels=
```
If the above examples were implemented, perhaps you would not need the configure step any more?
Something I personally find useful in terms of check organization is to organize checks and integrations in projects so that all checks in a project use all integrations. For example, suppose I have a project with 51 checks and 2 integrations (email and SMS). 50 of the checks use ony the email integration, and one check uses the SMS integration. In this case I would move the one check and its integration to a separate project. I can then add new checks in the project and not worry about deselecting the SMS integration for every new check.

@cuu508 commented on GitHub (Jun 26, 2023): You are right, I made a backwards-incompatible behavior change regarding the handing of non-existent slugs. Before the change, pinging a non-existent slug returned HTTP 404. After the change, Healthchecks [auto-provisions the check](https://github.com/healthchecks/healthchecks/issues/626) and returns HTTP 200. I should have been more careful about rolling out this change, and I am sorry for the disruption. > Suggest making auto-creation of slugs an opt-in feature that wont break code that relies on getting a 404 for a non-existent slug. Long-term, I want auto-provisioning be the default, and, ideally, the only mode. I'm assuming your use case is (please correct me if I'm wrong): * ping a slug * if the ping request returns 404, assume the check does not exist, and create and configure it using Management API And the problem with auto-provisioning and the 200 responses is, you now cannot easily detect if a check was just created and needs to be configured. If that's the case, I have a couple of ideas: * Improve the auto-provisioning code to return HTTP 201 instead of HTTP 200 if a check was just created. This would allow you to detect if a check was just created. Instead of checking for 404, you would check for 201. I can implement this relatively quickly. * I'm considering adding ability to configure some aspects of the check when auto-provisioning it like so: ``` curl https://hc-ping.com/<ping-key>/<slug>?timeout=300&grace=600 ``` Perhaps there should also be a way to say "and please do not assign any channels to it": ``` curl https://hc-ping.com/<ping-key>/<slug>?timeout=300&grace=600&channels= ``` If the above examples were implemented, perhaps you would not need the configure step any more? * Something I personally find useful in terms of check organization is to organize checks and integrations in projects so that all checks in a project use all integrations. For example, suppose I have a project with 51 checks and 2 integrations (email and SMS). 50 of the checks use ony the email integration, and one check uses the SMS integration. In this case I would move the one check and its integration to a separate project. I can then add new checks in the project and not worry about deselecting the SMS integration for every new check.

kerem commented

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

Author

Owner

@bdd commented on GitHub (Jun 26, 2023):

Following Pēteris's contribution, I made a prerelease of runitor supporting 201 response code so it doesn't think ping failed. If you use runitor, I'd appreciate testing reports of v1.3.0-beta.1. If no issues are found I intend to cut v.1.3.0 on Wednesday (PDT morning, UTC early evening).

@bdd commented on GitHub (Jun 26, 2023): Following [Pēteris's contribution](https://github.com/bdd/runitor/pull/118), I made a [prerelease](https://github.com/bdd/runitor/releases/tag/v1.3.0-beta.1) of runitor supporting 201 response code so it doesn't think ping failed. If you use runitor, I'd appreciate testing reports of v1.3.0-beta.1. If no issues are found I intend to cut v.1.3.0 on Wednesday (PDT morning, UTC early evening).

kerem commented

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

Author

Owner

@cuu508 commented on GitHub (Jun 27, 2023):

I changed the auto-provisioning logic to make it opt-in:

No auto-provisioning:

curl https://hc-ping.com/<ping-key>/<slug>

With auto-provisioning:

curl https://hc-ping.com/<ping-key>/<slug>?create=1

This is deployed to healthchecks.io, and the the documentation is also updated to match.

@cuu508 commented on GitHub (Jun 27, 2023): I changed the auto-provisioning logic to make it opt-in: No auto-provisioning: ``` curl https://hc-ping.com/<ping-key>/<slug> ``` With auto-provisioning: ``` curl https://hc-ping.com/<ping-key>/<slug>?create=1 ``` This is deployed to healthchecks.io, and the the documentation is also updated to match.

kerem referenced this issue

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

[GH-ISSUE #1065] [Docs] Reverese Proxy #740

kerem referenced this issue

2026-02-26 00:30:22 +03:00

[PR #597] [CLOSED] Enable Django setting CSRF_TRUSTED_SOURCES #997