Make URL display in check_httpv2 more transparent and user-friendly

Sometimes I really wonder what the thought process behind this design was.

The details section of check_httpv2 is generally clear and well structured - except for the URL. Why is the checked URL hidden behind an unnecessary icon and only visible when you hover over it? In my opinion, the URL is the most important piece of information for the alert recipient, as it indicates which site is actually being checked and experiencing an issue.

And when “Follow the redirection” is enabled, why does the check once again display the final reached page behind that same icon, instead of showing both the originally requested URL and the one where the process eventually got stuck? After all, the most important piece of information for the alert recipient is the URL of the website being checked.

It makes no sense that the Summary and Details sections contain identical information without providing any added value. It’s a paradox: when everything is fine, plenty of information is displayed – but when a problem occurs, the presentation becomes minimalistic and hard to understand.

In today’s increasingly complex IT environment, it is important to present information in a clear, transparent, and comprehensible way. This ensures that alert recipients can quickly understand the situation and respond appropriately.

If the same alert message looked like this, it would be much clearer for everyone – even for those who are not familiar with the service:

URL to test:   https://my.domain.de/api/health
Redirected to: https://my.domain.de/oauth/authorize?response_type=code&....
Method:        GET
Version:       HTTP/1.1
Status:        302 Found
Error:         Connection refused by https://my.domain.de/oauth/authorize

It would be so easy to simplify life for alert recipients by presenting all relevant information clearly and in a single location. Displaying or storing the received output for later analysis would be extremely helpful, as issues often cannot be reproduced afterward and the business department frequently asks, “What was displayed on the page when the error occurred?”

I’m honestly frustrated with having to submit such obvious usability improvements through the ideas portal, only to watch them sit there for years without any visible progress or action being taken.

4 Likes

Makes sense to me at least, will ask the team to look into that.

2 Likes

@LaSoe
as a woraround you can use the Escape HTML in service output (Dangerous to deactivate - read help) rule to let Checkmk show the URL instead of the :globe_with_meridians: icon.

Version: HTTP/1.1, Status: 200 OK
Details	URL to test: https://thl-cmk.hopto.org/
Followed redirect to: https://thl-cmk.hopto.org/explore
Method: GET
Version: HTTP/1.1
Status: 200 OK
Response time: 0.665 seconds
Page size: 94418 Bytes
User agent: checkmk-active-httpv2/2.4.0

Cheers
Thomas

2 Likes

@thl-cmk

Thank you very much for the tip. I wouldn’t have thought of that in this context.

Before, with “Escape HTML …” set to “Escape HTML” :

After changing the setting to “Don’t escape …” :

grafik

Now the link is visible but no longer clickable, which is perfectly fine for me. Copying and pasting it works just as well.

You never stop learning :slightly_smiling_face:

So the only thing missing now is the “Redirected to: …” Line in case of a redirect.

Here is the link to the Ideas Portal.
https://ideas.checkmk.com/suggestions/704699/check_httpv2-display-the-checked-url-directly-instead-of-hiding-it-behind-an-ico

And while we’re at it – it would be really helpful if the service check command could be used as a condition in the rules.

https://ideas.checkmk.com/suggestions/705699/rule-condition-allow-rule-conditions-to-target-a-specific-check-eg-check_mk_acti

This would make it much easier to apply such changes consistently across all services that use the same check. Currently, “HTTP” also appears in other service names that are unrelated to this specific check, which makes targeted adjustments a bit more cumbersome.

should be in there…

Hmm, strange that I missed that :thinking:. I probably missed it because, for this particular check involving a redirect, the Details section displayed an error message instead of the usual output (see screenshot). The other check i checked didn’t include a redirect, so its behavior looked different.