Make per-stack (IPv4/6) status more accessible
Currently, many of the downtimes I experience affect only IPv6, whereas IPv4 continues to work as usual. However, there are currently several places in updown.io where it doesn’t distinguish between such a partial outage and complete unavailability (IPv4/6 both down). In those cases, it simply marks the check as “down”. This is a real shame given that updown.io already has dual stack monitoring out of the box and is able to show separate statuses on the dashbord like in the attached screenshot (which is awesome!). It would be extremely useful to have this data exposed elsewhere as well, in particular:
- More meaningful notifications, for example “IPv6 down” instead of just “down” when IPv4 is still up
- Exposing per-stack up/down status in the api/webhooks
Thanks for considering this, and also for building such a cool service in the first place 👍
Looks like I forgot to update this but it has been implemented last year: https://headwayapp.co/updown-release-notes/less-visibility-for-partial-connectivity-issues-(ipv6-only)-176227
Since then partial (IPv6-only) downtimes are easier to distinguish and they don’t impact global availability numbers.
-
@Sjon indeed in an ideal world this would be nice but as you said it doesn't play well with the minimal UI and pricing. That being said we definitely provide the IP that is monitored when you receive downtime alerts, the IP tested is visible in the list of last 5 requests. (also in the detailed results in the downtime API as mentioned in this suggestion)
-
Sjon commented
I don't want to hijack this issue but it would be nice if both v4/v6 and multiple v4 addresses could all be resolved and visualized. I realize this doesn't fit in the current minimal UI, but ideally:
* all A / AAAA records are resolved for a domain
* all resolved addresses are monitored
* downtime on any of them is visualized separately
* wether or not the entire domain is considered as being down could be part of the configurationCurrently, for domains with multiple A records, there is no proper display of which addresses are actually monitored
-
Mark Dorison commented
I am experiencing this issue and would love to see some more options around this.
-
"I think I misread the description of the results parameter, I thought that parameter was for historical up/down data, even though that is actually the purpose of the endpoint it belongs to…" → don't worry that's not your fault, this parameter isn't explained much and is not shown in the example because it's quite new and kind of beta so I prefer people to start using it slowly ;)
-
Jakob Gahde commented
Yeah, I intentionally created that half-down check to specifically to check for this behaviour, since it is quite important to me. I’m glad that only something trivial like that was the issue here.
Also, good to hear the data is already available in the API as well! I think I misread the description of the results parameter, I thought that parameter was for historical up/down data, even though that is actually the purpose of the endpoint it belongs to… 🤦 Well, thanks for clearing that up!