updown release notes updown.io

New

Due to requests for some special use-cases like testing slower processing APIs, the 4s and 8s Apdex thresholds have just been added (previously the maximum was 2s):

⚠️ This is for endpoints which have an expected (and satisfactory) response time between 2s and 8s (e.g. aggregator, price comparator, file treatment, AI, etc..). This is not just a way to hide the performance issues of your website and make your status page looks greener 🙈

As usual this will impact your Apdex numbers, charts and the colors in your response time chart:

Additionally, to limit the number of buckets in this chart and improve readability we now group together the less relevant ones. In the above example, there's a single 0-500ms bucket whereas when using a lower apdex threshold you would see 0-125ms, 125-250ms and 250-500ms. Similarly when using a lower apdex threshold, the 8s-16s and 16s-32s buckets would be groupped in the "8s+/err" bucket as before.

Improvement

After the Private status pages earlier this year, it is now possible to choose the Protected visibility for multi-site status pages. This time it's only visible for users who have the configured access key or direct URL (which simply includes the access key):

The access key can be customized if you want. Also, unlike in Public mode, individual status pages will all be accessible thanks to the access key, no matter if they are set to public or private.

Improvement

It's now possible to choose between Public or Private visibility for multi-site status pages. Private meaning it's only visible for users connected to the updown.io account.

This feature has been requested a couple times here. Also requested was an intermediary Protected visibility, with a publicly shareable but non-guessable and non-indexable URL. This will also be added soon!

New

TCPS (TCP+TLS/SSL) check have been implemented 🎉

It performs both:

1. The TCP connection check for uptime (making sure the server is reachable and accepting connection), like the existing TCP check.
2. The TLS handshake and verification of the certificate (+expiration reminders), like the existing HTTPS check.

The feature had been requested here in order to monitor any kind of non-HTTP services using TLS encryption (such as SMTPS, IMAPS, LDAPS, some VPNs, etc.).

You can finally enjoy TCP port monitoring and TLS certificate verification:

Let me know if you have any problem with it 👨‍💻

Improvement

After the domain expiration reminders which have been added earlier, you'll now be able to see the domain expiration date in your dashboard by hovering the scheme or domain (like for SSL certificate expiration):

The scheme will be orange if the domain is approaching expiration (<= 14 days) so you can more easily notice them, even if you did not enable the alerts.

Also a list of domain names expiring soon has been added at the top of the weekly report email, just below the list of SSL certificates expiring soon.

For the record, the domain expiration date is not updated frequently, because RDAP and WHOIS servers don't like this. By default it updates every 1000 uptime checks (so up to 1000h/41d if you have 1h interval checks). But this interval is greatly reduced (max 24h) when it's getting closer to expiration (15 days before), so you get more accurate warnings. Keep in mind it's possible to see an outdated value here, especially if the expiration date is far in the future. The time of the last update is shown in the popup.

New

🚀 HTTP/2 protocol is now supported since June 11th, 2022. It is used by default when available, like in most HTTP clients. A small tag has been added to the dashboard to show if your website is monitored using HTTP/2:

Improvement

🛑 It is now possible to stop following redirects by providing the HTTP redirect status code in the "contains" field. Read more.

💡 updown now detects websites redirecting from dual-stack to IPv4-only server in order to automatically disable dual-stack monitoring. This avoids receiving alerts saying IPv6 is broken when you can't improve the situation, and it no longer have to be disabled manually. Read more.

📱 SMS alerts are now limited to 100/day/account in order to avoid draining credits too quickly during big outages, and also to prevent network operators throttling.

New

The multi-site status pages released a couple months ago now have their API so you can automate the creation and maintenance of these pages, check out the endpoints documentation here.

You can use these API endpoints to update the list/order of websites, the name and description (to automatically update in case of planned maintenance for example or known problems).

New

The first version of the recipients API has been released, it allows to list all possible recipients in your account (/api/recipients endpoint) and to modify the list of recipients selected for each check (recipients attribute in the /api/checks endpoints). You'll find the updated documentation here: https://updown.io/api

So you can now perform the same changes as on the bulk edit page but from the API, and thus automate the creation/update of checks while selecting only some recipients.

It is also possible to add new recipients (email, sms, webhooks, etc..) from the API using the POST endpoint.

Let me know if this is working well for your needs and if you notice any issues.

🧑‍🏫 Pro tip: before playing with the API and messing with your configuration, you can open the bulk edit page to have a snapshot of your current recipients configuration (as checkboxes). This way in case of problem you can just submit this form to restore the snapshotted configuration (don't reload the page before of course 🙃).

New

After months of development and beta testing, we are now releasing the domain expiration reminders feature publicly. The goal is to warn you a couple days before your domain expires in case you forgot to renew it. This feature is disabled by default, you'll need to enable it in your settings if you want it:

(this is because for many people it'll probably be useless and noisy)

⚠️ Note that some TLDs do not share expiration date or simply refuse to run an open RDAP or WHOIS service so this will not work with ALL domains but so far our success rate is about 80%. If your TLD supports RDAP (you can verify with https://rdap.org/domain/example.com) and gives an expiration date here you should be good to go. If your TLD does not support RDAP but responds to WHOIS queries and has an expiration date, most of them will be supported by our parser, if not feel free to open an issue or a PR or just ask us and we should be able to add support.

Improvement

Since the beginning it has not been possible to specify an expected HTTP status code (though it was possible to specify a string to search in the body response, which often allowed to circumvent this limitation).

Well it is now possible to specify an expected HTTP status code (other than the default 2xx), in the same place you could specify a string to search, the tooltip has been changed accordingly:

This can be useful if you need to monitor an endpoint with a non 2xx status but which doesn't return any body (or not stable enough to match on). The error message will be the same for now: UP/DOWN (short version) or "Couldn't find the configured string" (long version) because it's simpler. I'll see about changing that a bit if it creates confusion.