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...)

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

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.

Currently updown.io will follow 302 redirects when checking if a service is up. In the curl commands that are emailed when downtime is detected, this is achieved via the -L flag. It would be good if this could be disabled, so that the actual endpoint given is tested and not the endpoint at the end of the 302(s).

An example of when this might be useful: I have a few endpoints that simply 302 to another endpoint, which I don't maintain / own / have any control over. I'm less interested in whether those endpoints are up, and more interested in whether my endpoints are up.

I've also noticed that when a 302 is followed, the SSL analysis is carried out on the final SSL certificate, not the server that issued the 302. Again, it would be useful if we could disable following 302's so the SSL certificate that I manage on my endpoint (which serves the 302) is monitored instead.