custom name instead of automatically generated UUID

[s-h-a-r-d]

Could we get a possibility to use a custom name in URL instead of randomly generated UUID?

So instead of url being something like healthchecks.example.com/ping/543dc814-81a5-11eb-8dcd-0242ac130003
I would like to be able to set it to something like healthchecks.example.com/ping/name-of-my-service

For example I would then be able to specify the URL in docker-compose like this:

healthcheck:
      test: ["CMD", "curl", "-f", "https://healthchecks.example.com/ping/name-of-my-service"]
      interval: 60s
      timeout: 10s

and would not have to first create the endpoint in healthchecks and then update the url to docker-compose.

Is this possible to achieve currently? and if not is this something that is feasible to implement?

[cuu508]

I like this idea and wish I had thought of it from the start.

There has also been interest in additional authentication for the ping endpoints. Let's say there was a per-project "ping key". The ping URLs could look something like:

healthcecks.example.com/ping/<ping-key>/<name-of-service>

Let's say I have a web application that runs 10 periodic processes I want to monitor. Currently, with UUIDs, I have 10 different ping URLs. I must treat each ping URL as a secret – the same way I would be treating database credentials, SMTP credentials etc. The UUIDs are not human-readable – it is easy to mistake one ping URL for another.

Now, with a "ping key" and custom names, I would only need to treat the ping key as a secret. It would be easy to construct all 10 ping URLs from just the key and the custom names (which don't need to be secret).

Is this possible to achieve currently?

No

and if not is this something that is feasible to implement?

I think yes, but it would take a fair bit of work. I think I could hack something together relatively quickly, but the main effort would go into

• making the UI support both UUIDs and custom names, without cluttering it too much
• making the Management API support both UUIDs and custom names
• updating docs to clearly describe the differences between "legacy URLs" and "new URLs"
• managing complexity

[ivmilicevic]

Is this issue in a roadmap? It would be great feature to have

[cuu508]

There isn't really a roadmap but yes, I do plan to work on this feature.

I'm taking a closer look at it now and putting together a plan (all subject to change).

• Add a Project.ping_key database field. Show it in project's "Settings" page, next to API keys
• There needs to be a way to reset keys selectively – reset just the ping key, or just the API key
• Use slug versions of check names in ping URLs (in the below screenshot, "KGAsb5V2bzqr" is the ping key):

• In project's "Settings" page, let the user select which URL style (UUID or ping_key/slug) to display in checks list and in the details pages. Regardless of which style is selected for display, both styles would work for pinging.
• For pinging via email, at least initially, leave everything as-is and support only UUIDs.
• If multiple checks in the project have the same slug, they can't be pinged using the ping_key/slug method

On the last point: let's say the project has two checks with the name "Database Backup". What should happen when a client pings "database-backup"? We have a few choices:

• Don't ping either, because the slug is not unique
• Ping the first check with a matching slug (the oldest one?)
• Ping both checks

I think the first option is the correct choice – I think errors and failures should be loud and explicit. If you want to ping a check by its name, then the name has to be unique within the project. If you use non-unique slug anyway, neither check registers a ping, which eventually triggers notifications, and you can then investigate.

Comments, ideas, suggestions welcome!

[cuu508]

An initial version is ready and deployed to https://healthchecks.io. In the checks table, "Ping URL" column, there is now a uuid/slug switcher:

You can generate the ping key in project's Settings page:

HTTP status codes when using {ping_key}/{slug} URLs:

• 200 OK – the ping key is correct, a matching check was found, the the ping has been recorded
• 400 Bad Request – the URL does not match the format (unexpected characters, unexpected number of slashes etc.)
• 404 Not Found – check with a matching ping key and slug was not found
• 409 Conflict – the slug matched more than one check, the request is ambiguous and was ignored

Healthchecks.io also does rate-limiting at nginx level:

• 429 Too Many Requests – rate-limit exceeded. The rate limit is currently 10 requests per minute per check.

The documentation is not yet updated with the new URL format – I wanted to get this early version out so you can try it out :-)

[AlexBlack772]

thank you, an awesome feature !!! works fine