It sometimes occurs that a website which is no longer hosted by us goes down and has not (yet) been removed from updown.io. When we see a notification about such a website, it is usually removed from updown.io so it is no longer checked.

Once it goes down, a webhook is sent and a monitoring-system alerts us of this error. If the website is removed from updown.io, there is no event to notifiy our system of this change, so the error persists.

It would be great if the deletion of a website sends a webhook so your custom system could process this.

Hi,
I have implemented a simple php script on one of my servers to take a query via GET method and returns the requested DNS record.
The site is restricted to updown.io servers and uses a URL in the following format :

https://webserver.com/lookup.php?T=A&D=google.co.uk&R=IP

This uses the following fields :
T - Type of record to return eg. MX/A/TXT
D - Domain to check eg. google.co.uk
R - Record field to return. eg. ip for ip address
The server code simple checks if the record type is a valid one we accept, checks the domain name is in a valid format and then performs a PHP dnsgetrecord(), it then checks if the R field is in the result and returns it if it is. If there are multiple matching records, then it simple returns them all separated by a ',' this allows using the 'contains' field within the check portal to check for the required data.
This allows me to check that a DNS record hasn't been changed by a third party (eg. I host a customers web page, but all there DNS etc is handled by someone else).
Would be happy to supply the scripts if anyone is interested, would be great to add to updown as a service (with rate limiting etc!)
marl_scot

updown.io is STUPENDOUSLY inexpensive compared to most other uptime monitoring solutions available today. This is obviously one of your strongest selling points.

So, "hiding" detailed pricing information on the logged-in-users-only page https://updown.io/credits/buy seems counter-productive. I was especially surprised by the big discounts given when buying credits in bulk. It seems to me that a version of this page (or equivalent information) should be made available for everyone, even if they haven't signed up for the service yet or are currently logged out. (This would make it easier for fans to share this information with friends or other prospective users, as well. Yay virality?)

The pricing widget at https://updown.io/#pricing only gives a very rough idea of the cost. I think a link to a public detailed pricing information page should be added to it and would greatly help with marketing. I certainly didn't realize how crazy inexpensive updown.io really was before I signed up and checked the "buy credits" page.

Now you may think, "but prospective users can just sign up since it's free", but you have to realize that many people are not that eager to sign up to new services just to evaluate them. You are nominally competing with dozens of uptime monitoring services out there, despite the fact that almost all of them are crap and/or hilariously expensive.

For instance, I had initially passed over your service and ended up with Uptime Robot (which honestly is not too great). If someone hadn't "randomly" mentioned your service when I experienced reliability problems with Uptime Robot, I might not even be here...

There's also a bit of a transparency component to this. Right now your service SAYS it's inexpensive, and it's true, but a public detailed pricing information page would PROVE it, which is much better.

(Sorry for the slightly long-winded suggestion, I have neither the time nor energies to write a shorter one...)

I raised this same issue under this discussion almost two years - unfortunately it's been completely ignored: https://updown.uservoice.com/forums/177972-general/suggestions/38068798-add-the-ability-to-disable-following-redirects.

I've worked around this in the past but it's starting to cause problems again, so I'm raising it again and this time I'll expand on the specifics of the problem I'm having.

I run web services from behind Cloudflare. When you set up Cloudflare for proxying, you provide your backend DNS entries to them and enable proxying. They'll then create public facing DNS entries for you that point to Cloudflare, and proxy connections through to your backend. For this, Cloudflare automatically add public AAAA records for all your endpoints. This is usually fine and doesn’t require your backend to support IPv6 because Cloudflare will handle consuming the IPv6 connection and proxying it to the IPv4 backend.

However, when the IPv4 backend then responds with a e.g. a 302 redirect, and the target of that redirect doesn't support IPv6, updown.io reports this as a partial connectivity failure.

This is because of the curl command used, i.e. 'curl -gkvLI6 redirect.example.com'. This command will force curl to resolve 'redirect.example.com' on its AAAA record, receive the redirect (e.g. 302), and then force it to attempt to resolve the redirect target on its AAAA record. If no AAAA record exists for the redirect target (due to lack of IPv6 support) or the backend does have a AAAA record by no IPv6 listener, the curl command fails and this is reported as a partial failure in updown.io.

The only way I think that this problem could be solved by updown.io is to offer the option of preventing the curl check from following redirects, i.e. toggle the '-L' flag off. This would let me check the health of my IPv4 and IPv6 facing endpoint without having to worry about the status of the redirect target, and then check the health of the redirect target itself separately.