[GH-ISSUE #1025] Display cloaked URL in user interface #713

New issue

Open

opened 2026-02-25 23:43:21 +03:00 by kerem · 3 comments

kerem commented

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

Owner

Originally created by @daviewales on GitHub (Jul 10, 2024).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1025

When writing documentation, it would be nice to be able to link to specific Healthchecks by their cloaked URL. However, the only way I can see to get a copy of the cloaked URL is to trigger a failed ping and extract the cloaked URL from the notification.

Would it be possible to make the cloaked URL visible in the user interface?

The problem is that that set of people who can read the documentation is greater than the set of people who have access to Healthchecks, so I don't want people gaining the ability to ping Healthchecks who shouldn't have this access.

Originally created by @daviewales on GitHub (Jul 10, 2024). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1025 When writing documentation, it would be nice to be able to link to specific Healthchecks by their cloaked URL. However, the only way I can see to get a copy of the cloaked URL is to trigger a failed ping and extract the cloaked URL from the notification. Would it be possible to make the cloaked URL visible in the user interface? The problem is that that set of people who can read the documentation is greater than the set of people who have access to Healthchecks, so I don't want people gaining the ability to ping Healthchecks who shouldn't have this access.

kerem added the

feature

label

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

kerem commented

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

Author

Owner

@cuu508 commented on GitHub (Dec 11, 2024):

I've looked into this a few times. The technical side is trivial, but the problems I'm running into are:

where to tuck it into the UI (so that it does not confuse people who do not need cloaked URLs)?
how do I explain to users what a "cloaked URL" is? There would probably need to be a new docs page explaining it by going through an use case.

@cuu508 commented on GitHub (Dec 11, 2024): I've looked into this a few times. The technical side is trivial, but the problems I'm running into are: * where to tuck it into the UI (so that it does not confuse people who *do not need* cloaked URLs)? * how do I explain to users what a "cloaked URL" is? There would probably need to be a new docs page explaining it by going through an use case.

kerem commented

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

Author

Owner

@daviewales commented on GitHub (Dec 11, 2024):

One idea might be to always use cloaked URLs when navigating the UI. So, when I click on a HealthCheck in the UI, instead of going to a page with the URL healthchecks.io/checks/uuid, I would instead navigate to a page with the URL healthchecks.io/checks/hash.

The idea is that the UI page and the ping endpoint have different addresses, so I can share a link to the UI page in my wiki, but only people who have access to HealthChecks can visit the page to see the UUID and initiate pings, etc.

You could continue to resolve healthchecks.io/checks/uuid addresses for backwards compatibility.

Cons:

This would confuse people who expect that they can copy the end of the UI page URL as the UUID.
This may break existing users' expectations

Pros:

No changes to the interface are necessary.
People can continue to copy the ping URL from the How to Ping section of the UI page.
New users will hopefully understand that the UI page URL and the ping URL are different.

@daviewales commented on GitHub (Dec 11, 2024): One idea might be to always use cloaked URLs when navigating the UI. So, when I click on a HealthCheck in the UI, instead of going to a page with the URL `healthchecks.io/checks/uuid`, I would instead navigate to a page with the URL `healthchecks.io/checks/hash`. The idea is that the UI page and the ping endpoint have different addresses, so I can share a link to the UI page in my wiki, but only people who have access to HealthChecks can visit the page to see the UUID and initiate pings, etc. You could continue to resolve `healthchecks.io/checks/uuid` addresses for backwards compatibility. Cons: - This would confuse people who expect that they can copy the end of the UI page URL as the UUID. - This may break existing users' expectations Pros: - No changes to the interface are necessary. - People can continue to copy the ping URL from the `How to Ping` section of the UI page. - New users will hopefully understand that the UI page URL and the ping URL are different.

kerem commented

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

Author

Owner

@likuilin commented on GitHub (Jun 21, 2025):

Adding it as an extra option in the Status Badges page, so that the badge can optionally link to the cloaked URL, might be a user-friendly way of doing it. The badges page already explains that the badge URL is hard-to-guess, and the cloaked URL is for a similar broad purpose.

This way, the additional fact that the cloaked URL can be used by itself to refer to a check safely (more specifically, there being no public way to check the status / see the badge from just the cloaked URL) does not need to be explicitly said.

@likuilin commented on GitHub (Jun 21, 2025): Adding it as an extra option in the Status Badges page, so that the badge can optionally link to the cloaked URL, might be a user-friendly way of doing it. The badges page already explains that the badge URL is hard-to-guess, and the cloaked URL is for a similar broad purpose. This way, the additional fact that the cloaked URL can be used by itself to refer to a check safely (more specifically, there being no public way to check the status / see the badge from just the cloaked URL) does not need to be explicitly said.