Thanks for the suggestion, this is something which have been asked a couple times in the past and is under review for the roadmap.

Quick question: if this is for website which have a public status page, how would you feel about a public (no api key) read-only API for them?

Or do you prefer one read-only API key per check?

Good suggestion, that is definitely a pain point. But I have a little hack for this (which I personally use), not very pretty but efficient: Add an anchor at the end of the URL to indicate an alias of your choosing. This anchor will not be sent to your server (it’s a client-side HTTP feature) but it’ll show in your recipient list and bulk edit screen so it makes it easier to distinguish URLs, example:

https://example.com/xxxxxxx#project-A
https://example.com/yyyyyyy#project-B

Thanks for your offer, I just sent you the translations by email.

Hello, this is a good suggestion indeed. Once the status pages are released (which will share this UI) it’ll be a bit tricky to get right in order not to share private information like basic auth passwords or API tokens but it sounds doable.

Hi, 2 months ago we started providing canonical URLs so search engines would only display a single result (without the localized version) but it looks like this is not enough and multiple versions are still indexed. We’ll probably add some noindex to help with that.
On the other end we’re not gonna totally block the indexing of the main status page because this is a feature, being able to lookup a status page when the monitored service is down can be useful.

Thanks for the suggestion, I’ve just merged this with another one about DNS check. This is something we’re thinking about but is not planned yet.

In the meantime what you made is a great workaround, if other users are interested I encourage them to leave a comment here with a way to contact them so you may give them the URL of your service if you want.

Hello,

Actually 14, 7, 1 is already the special schedule for let’s encrypt certificates. This is automatically detected by updown.io so you don’t have to, normal 1-year certificates get an additional 30 days reminder.

The threshold for let’s encrypt certs starts at 14 days because the default renew delay is 30 days before expiration: https://certbot.eff.org/docs/using.html. This can be down to 23 days with a weekly cron for example (pretty common) so that’s why we chose 14 days, so you have plenty of time to renew but still have time to investigate and fix any potential auto-renew issues.

If you’d rather renew your cert only 5 days before expiration that’s up to you but we won’t recommend or support this configuration as we consider it dangerous ☺

I’ll mark this suggestion as “Under Review” to measure the need for this.

Yes, I want to do it for a long time but the Qualys API is not free to use for commercial projects so I need to discuss with them (this is currently in discussion).

Ok I’m moving this back to “under review” as it’s gathering a lot of interest, but this would require first https://updown.uservoice.com/forums/177972/suggestions/16982392 and https://updown.uservoice.com/forums/177972/suggestions/15589635 to be implemented to provide a decent UI for this.

Hi all, there’s now an option for that which is through Zapier (we just added native Zapier integration): https://updown.uservoice.com/knowledgebase/articles/1911991

Using this you can connect PagerDuty and receive alerts from updown.io. I’m keeping the suggestion “under review” because we might provide a native integration later.

I like the idea ☺

Hi all, there’s now an option for that which is through Zapier (we just added native Zapier integration): https://updown.uservoice.com/knowledgebase/articles/1911991

Using this you can connect pushover.net and receive alerts from updown.io. I’m keeping this suggestion “under review” to gather interest about a native integration with pushover.

While I understand the need, being in China is a lot of work (mainly support and maintenance) as the network conditions are erratic and with out current double check policy would not actually notify if your website is unreachable in China (unless we have two servers here and become a regional monitoring service but that’s not the objective and we can’t just do that in every country). I’ll keep the idea open to measure interest. Also if some of you have recommendations for a dependable and affordable hosting provider in China I’m interested.

There’s no UI for this yet but feel free to ask support if you need, we can bulk add for you.

Nothing planned so far, but it’s already possible to use the API (with the read-only API key) to build a custom javascript widget directly

What would this be useful for?