HTTPs is becoming the “default” for any website whether it is a blog, portal, e-commerce or corporate one.
However, a website with an SSL certificate requires an extra layer of monitoring, “making sure the SSL works as expected”, as a certificate:
- can expire
- can produce errors (host mismatch, use insecure protocols like SSLv3..).
Introducing SSL monitoring
The Pro Plan now monitors such cases and lets you know:
- when the SSL certificate has errors including:
- host mis-match
- forcing insecure protocol (like SSLv2 or SSLv3)
- and when the SSL certificate is getting close to expiry date (when 30, 15, 7 and 1 day is left) so that you can renew it in advance.
Note: “mixed-content SSL warnings and revoked certificates” are currently not supported.
The feature is available by default for all HTTP and keyword monitors whose URLs start with “https”.
Customizing its usage
It is possible to:
- disable SSL monitoring and/or “ignore SSL errors” for selected monitors from the “Add/Edit Monitor dialogs”. This is handy if the website uses a self-signed certificate.
- choose which alert contacts will get “SSL expiry notifications” from the “My Settings>Alert Contacts>Add/Edit Alert Contact dialogs”.
- By default, all alert contact types except “SMS, mobile Push, Pushbullet, Boxcar and Pushover” are enabled considering they are non-intrusive.
Important info: The feature will become active by 20 September 2017 to make sure any customization can be performed in advance.
Excited to have this feature being available and hope that it helps for a better uptime :).
Update (24 Oct 2017)
Thanks to all the feedback received, we have applied a set of updates to make sure that this feature is easy-to-use and functional for everyone:
- a certificate being self-signed is no more a reason for it to be detected as “down”
- monitors with IP-based URLs (like https://126.96.36.199) are not checked for SSL errors
- expiration notifications for certificates by Let’s Encrypt and Cloudflare are only triggered if 3 days or less are left for expiry as these certificates are mostly auto-renewed close to the expiry date.
- ssl settings for all monitors can be changed in bulk using the bulk actions dialog (can be found just under the “Add Monitor button”).
Cloudflare is an impressive service/platform for securing and speeding-up websites.
If you use Cloudflare and have a “status page with a custom-domain” in Uptime Robot, “there may be a small configuration needed” to make sure things work smooth.
Who needs the custom configuration?
If the 3 items below match your case, then the custom config is needed:
- Use Cloudflare as your domain’s DNS provider
- Have a status page with custom domain in Uptime Robot
- Have the “Crypto” setting as “Flexible” in Cloudflare
How to make the custom config?
That is so easy:
- Login to your Cloudflare account
- Click the domain of your status page
- Click “Page Rules>Create Page Rule”
- Enter *MyStatusPageCustomDomain* (like *status.mydomain.com*) into “If the URL matches” field
- Click “Add Setting>SSL>Full”
- Click “Save and Deploy”
- That’s it.
And, here is a screenshot of the setting:
For HTTP monitors, Uptime Robot considers them as up or down according to the HTTP statuses returned (or if “no response returns at all”).
If the HTTP status returned is:
- between 200 and 399, it is considered as “up”
- bigger than 399, is considered as “down”
- with an exception:
- equals 401 and no authentication info is defined, it is considered as up
- equals 401 and authentication info is defined, it is considered as down
It is now possible to customize which HTTP statuses are considered as up or down.
This is pretty handy if you plan to monitor a web page which returns HTTP 404 and want it to be detected as “up”, prefer to ignore several erroneous HTTP statuses and more.
The feature is available in the Pro Plan and can be reached from the “Add/Edit Monitor dialogs of HTTP monitors>Advanced Settings>Custom HTTP Statuses tab”.
Uptime Robot, by default, sends all HTTP requests with pre-defined HTTP headers.
Now, it is possible to customize this totally with the “Custom HTTP Headers” feature that can be found in the Pro Plan’s “Add/Edit Monitor Dialog>Advanced>Custom Headers” option.
Sample use cases:
- For monitoring the mobile version of a web page, we can use a mobile “User-Agent” header to force the site to serve the mobile content.
- The site may be requiring/expecting various authorization HTTP Headers
- We may want to white-label the requests and change the User-Agent to a custom one
Hope it helps for a better monitoring :).
Getting notifications of downtime/uptime via Slack or HipChat is widely used.
Yet, until now, it was only possible to “target” rooms and not users.
There is now a “custom text” feature in the “Add/Edit Alert Contact” dialogs for HipChat and Slack where the text mentioned there will be sent with each notification.
As an example, we can now use custom text like:
- @everyone for Slack to notify everyone
- @SlackUserID for Slack to notify a specific user
- @here in HipChat to notify all users in the room
- @all in HipChat to notify everyone in the room
- @HipChatUsername to notify a specific user
Hope this helps for a better experience :).
Public Status Pages, a feature to easily share the statuses of the monitors with others, was introduced few months ago.
The standard status page URLs (like https://stats.uptimerobot.com/xyz) were HTTPs-enabled since day one.
However, the ones behind a custom domain (like http://status.mywebsite.com) were not as it was a little more tricky to get a SSL certificate for all the custom domains.
Good news, custom domains are now HTTPs enabled too (thanks to the free + automated CA: Let’s Encrypt).
And, all status pages are actually HTTPs-only from now on.
Important note for CloudFlare users:
As the status pages are now HTTPs-only, the “flexible SSL feature of CloudFlare” will end up in an infinite redirect. There are 2 options to make it work:
- disabling the “cloud feature” for the CNAME
- or, using Full or Strict SSL feature
This entry was posted on by Umut Muhaddisoglu.
Uptime Robot’s API is consumed pretty much (with over 5,000,000+ requests/day) for “automating monitor management”, pulling the data to generate custom reports and more.
As the usage grows every day, the APIv2 is built for a faster, more secure and stable experience with added features.
SSL and POST only
The APIv2 expects all parameters to be sent as a POST request and works SSL-only where both changes together help making it more secure.
Updated parameter names and speed
The parameter names and responses are very consistent now. They are all lower-case, separated with “_” (like api_key).
And, most methods are now ~ 2x to 5x faster.
It is now possible to pull more data with
getMonitors method, including:
- getting the uptime % of a range (or multiple ranges) with
- getting the all time duration of statuses with
- getting the logs of a given period with
- getting maintenance windows of a monitor
And, maintenance windows can also now be managed with the API too.
The updated documentation page now has code samples for each monitor in multiple scripting and programming languages including PHP, Python, Nodejs, Go, Ruby, C# and Java.
When will APIv1 be retired?
APIv2 is the version that will be improved from now on and APIv1 is planned to be retired by 1 June 2017. So, please make sure that you switch to the new API before then.
Suggestions and bug reports
We are already using APIv2 in production, so, it is pretty stable. Yet, there is always a change of bugs and please let us know if you experience one.
Also, look forward to any suggestions and feature requests to make it better.
This entry was posted on by Umut Muhaddisoglu.