Custom HTTP Statuses (A New Feature for the Pro Plan)

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

Custom HTTP Statuses

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”.

If you find Uptime Robot useful, help us spreading the word:

Comments

  1. moshe alfih

    How do I get this on keyword monitors? Is there an API to control this? A mass update for existing monitors, or a global setting?

    Reply
    1. Umut Muhaddisoglu Post author

      This only exists in HTTP monitors as keyword monitors don’t take HTTP statuses into account.

      Reply
      1. jjpm

        Following up on moshe alfih’s question…
        Is there an option in the newMonitor and editMonitor APIs to manage this? We’d like to have a different set of status codes for UP on our monitors.

        Reply
    2. Umut Muhaddisoglu Post author

      Right now, the API covers this for HTTP monitors.

      Reply
  2. Dean Kostilek

    think we should add custom HTML Code to our website so we can get the status on our website so its all in one not differnt links

    Reply
    1. PeterA

      We built a webpage that proxies various requests into our internal services.

      Using this I validate that SMTP works (as in, sends an actual email), that SNMP monitors are returning values within an accepted range, and various other tests are up and running.

      404 implies the monitor relay is down, 500 implies the specific test has failed.

      The above change is good; it means if I wanted to, I could “ignore” 404 errors for all monitors (except the one that monitors the relay) and I could “error” on the monitors that should error only when they get 500 (which is a status that says it actually failed).

      Reply
      1. Umut Muhaddisoglu Post author

        Exactly.

        Reply

Leave a Reply to moshe alfih Cancel reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>