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 ☺

Thank you for the suggestion but we’ll not implement something this specific. This is not compatible with updown.io’s goal to be simple and inexpensive.

Unfortunately I’ll probably never implement any SLO/SLA as it’s not sustainable at my size (solo founder), it wouldn’t really make sense to refund money on a service costing so little IMO and most importantly I’d rather put efforts into making the product better than spending my time negotiating deals with bigger companies. I also prefer the simplicity and fairness of everyone paying the same price (proportional to usage) and having the same (good) service.

Indeed we don’t want too many options for simplicity but we do support custom intervals per client if needed so I’ve just granted you access to 15m and 20m intervals on your account.

Thanks for the suggestions but this would change the UI a lot and doesn’t fit our pricing model so it’s not going to happen.

Intervals above 1h may be available on demand depending on how many sites you are monitoring. Please ask support if you want.

The current values are 10s for connection timeout and 30 seconds for response timeout. I do not plan on allowing to increase those as it’s already pretty high.

Sorry but this won’t be added, we consider it to be a bad practice as this would miss most actual errors returned by your servers and drastically reduce monitoring quality (which would then be blamed on us). If you don’t care about the content present, just don’t use this feature and rely on standard HTTP status check.

We already do 2 double checks before notifying, which is enough to eliminate any false positive. If you want to ignore real but small downtimes, you should increase the check period.

The string search features allows to match on a text instead of a status, this is useful for testing special status responses. And a 503 (if properly used for maintenance) should be considered down, if you want to hide the downtime caused by maintenance from updown.io you need to disable the check before the maintenance.

Most website can easily respond in less than 0.5s even if queries from the other half of the world. We initially supported only up to 1s and added 2s later but we don’t want to encourage people into thinking 2s+ response time is acceptable so we won’t go higher. If your website is slower and this is acceptable to you it’ll of course monitor properly, but you’re not gonna be able to show an all green Apdex score.

No it can’t because we measure the time it takes until your server starts responding, not until we finished downloading the body. And we don’t download any body by default anyway as we use the HEAD http verb, only when you use the string search feature. So the page size is irrelevant to this measure.

This integration requires writing some custom PHP code, which means more maintenance, support and crappy UX. It’s just not worth for us. If someone really wants this extension he can write it using our API.

Hello Matt, I’m closing this in favor of: https://updown.uservoice.com/forums/177972-general/suggestions/11515134-monthly-reports, please move your vote and comments to this suggestion ☺

This would be more settings, complexity and cost which is against updown.io’s principle so we won’t do that.

Response time does not impact monitoring, it’s normal to have slower response time from further away locations. But in your case the latency from SF and Miami to Chicago is very small (<10ms) so the performance issue your are seeing is all on your side.

Unfortunately this is much more expensive and super unreliable so we’ll never use it for the main monitoring. Though at some point we may add some side features to try your website in a browser from time to time and let you know if it breaks for some reason but that’ll only be warning notifications (like we do with SSL alerts).
And most importantly it won’t be configurable, as this would require a very complex setup which is not in the updown.io philosophy

Thanks for your feedback, unfortunately we can’t really add all the number people want, the status page already have lots of them. We’ll probably add the ability to go back in history in the future (on the calendar view for example) but we most probably won’t add an annual uptime in the headline. You can get this number from the API if you want it though, the history is kept forever at the data level.

That won’t happen, there are plenty of good tools for this already (ex: nixstats) and would be too much work.