Categories
Announcements

A Change in Handling HTTP 401 Statuses

Quick links

    Uptime Robot treats all HTTP statuses equally. They mean either up or down… except HTTP 401.

    HTTP 401 is expected in some situations and not expected in others. Currently, HTTP 401 is handled as:

    • If auth info is mentioned in monitor’s settings but HTTP 401 is returned, monitor is marked as down
    • if no auth info is mentioned but HTTP 401 is returned, it is marked as up

    which looked like the best way at the early days of Uptime Robot.

    Yet, there are edge cases on both scenarios like “a monitor with no auth info returning HTTP 401” may also mean that the site/server is experiencing configuration issues and this must be detected as down.

    The change

    As there is now a Pro Plan feature to customize HTTP statuses, Uptime Robot will start treating HTTP 401 just like other HTTP statuses (which are equal to or bigger than 400):

    • will be considered as down by default no matter auth info exists or not
    • if needed, it will be customizable with the HTTP status customization feature.

    This change will give room to handling this HTTP status however preferred and the change is planned to go live on 1 March 2019.

    16 replies on “A Change in Handling HTTP 401 Statuses”

    It’s 2:30 AM here and I was just woken up due to dozens of checks suddenly reporting downtime. After figuring out it was caused by a change at UptimeRobot I then had to manually edit dozens of checks to resolve the incident. I’m done and heading back to bed now but needed to let you know that changes like this WILL wake someone up.

    While I understand the reason for this change I feel it could’ve been communicated better. Many of my employer’s checks (we have a few hundred total on a paid account) were designed based on the previous behavior. We had no notice that this was going to be changed and at just one week notice.

    Next time please consider: longer leadtime, email communication for a breaking change (!!!), bulk change feature for advanced settings like HTTP status, possibly a way to identify the effect of upcoming changes.

    Hi Martijn,

    First of all, very sorry for any trouble.

    We have actually sent a newsletter about this change a week ago and any chance that the user didn’t have the newsletter selection active?

    P.S> You are right that we must have kept the period longer and we’ll definitely be doing so for any possible future updates.

    Appreciate your reply.

    I’m afraid I don’t understand where it went wrong. I checked that we have both the “New features” and “Technical/API” mailings turned on and I just searched our entire mailserver for a missed newsletter in the past weeks but didn’t find anything. So I’m not sure what happened.

    Hopefully next time we’ll catch it in time. Thanks!

    P.S. I’d love to be able to bulk change the advanced settings as well as some kind of labels/tags to help manage large numbers of checks.

    Oh this is sad, now I can’t use this anymore. Took me a while to figure out why my service was reported as offline 🙁

    This change makes my use of the free account (for home use) unusable. I note there was no communication about this breaking change – I have checked my email.

    I also use such tools professionally. Such stuff-ups make it less likely to choose your services for my commercial needs. This was a big stuff up — I’d expect you to identify customers likely to be impacted in advance — those with 401 being the “up” state — and email them specifically about a breaking change.

    This was actually a logic bug on our end since years as it was the most ideal was of handling when HTTP status customization was not possible. Yet, totally understand that the customization is a Pro feature and we have/had no intentions to push users to using Pro for such a simple need. We simply needed to remove that logic from our engine so that the code and HTTP status handling becomes more straightforward.

    P.S> We actually communicated through e-mail to both of the newsletter lists, yet, from the comments, we see that it didn’t reach some users. Very sorry for that.

    I have a bunch of monitors that have successfully treated a 401 status as UP, but they now report DOWN. They do not have any AUTH settings (Auth is set to Basic, but the username and password fields are blank), but are you saying I must upgrade to the Pro account to get back to the original behaviour?
    Andrew

    So free users are no longer able to monitor a Website with HTTP authentication, without providing the credentials.

    For multiple reasons, I cannot provide the credentials. Guess I just have to stop monitoring that site.

    I second Martijn’s comment. I was woken up by a dozen e-mails and notifications. Wasn’t for a good while after speaking to people in engineering to find out that this was the problem.

    You have (and supply) an awesome service, but this was and still is very annoying and worrying. Considering now moving to another platform as I can’t trust the monitors now.

    If you are simply interested in the up or down status of your system, I found a work-around. Set up your monitor as a “port” monitor (port 80, 443 or any non-standard port you may use). The monitor will accept any response as UP.

    Its a bit of a compromise because it will also treat 500 codes as UP so you won’t be alerted to internal server problems, but it does give back some monitoring for sites using unsupported authentication.

    Hi,

    I have several monitors reporting as down on a regular basis. But they are up.

    Assuming this change affected my sites as well – what should I be changing my http checks to?

    I have 13 servers, each similarly configured. Since 3/2/2019, some servers show as UP, some Down.

    4 Servers appear normal and show Status “Up” with Event “Up”, Reason “OK (200)”.
    6 show as “Down” with Event “UP”, Reason “Unauthorized (401)”
    4 newly added servers show as “Down” with Event “Down”, Reason “Unauthorized (401)”
    Why are the servers reporting differently?

    I have other ways to monitor if the server is up and Ping only is not an acceptable test.
    What do I need to do so UptimeRobot reports Status correctly?
    How does the “Pro Feature” resolve this issue?

    Hi Martin,

    please send us all the details to support@uptimerobot.com if there are still any issues, but there were more changes lately so not sure if there’s still anything we can help you with 🙂 Just let us know!

    Leave a Reply

    Your email address will not be published. Required fields are marked *