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 👍
Thanks for your suggestion, well actually the first part is already implemented, when you have a downtime only on IPv4 or IPv6 it’ll say “DOWN (IPv6 only)” in the alerts. I see on your accounts that you didn’t saw this message because the checks were just created and already down, and we currently need at least one successful check on both stacks before to trigger this message. But thinking about this I’m not sure why so I’ll probably change this to make in work also in your case.
Also you’re right it should be added to the UI.
About the API and Webhook you can already get very detailed informations about dual stack tests in the /downtimes endpoint using the “results=true” parameter. I’ll gradually make more details available to other endpoints.
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!