FAQ  〉Why does updown think my website is down?

There can be a lot of reasons obviously so here we'll try to list the most common ones

HEAD requests

By default, updown uses HEAD requests instead of GET, which is supposed to be exactly the same just without sending the body (because if we don't need it, it saves ressources on both end). Of course if the server refuses to respond to HEAD requests (that would be with a 405 Method Not Allowed) or if the configuration on updown side forces the use of a GET request (if the "contains" field is used), then updown will fallback to using GET instead.

Unfortunately some website breaks this specification and sometimes return a different status between GET and HEAD (e.g. 500 Internal Server Error), in which case updown may not get the "correct" status (at least not the one you're getting in your browser). For this situation, when you add a new check updown try to automatically detect this behavior (by performing GET and HEAD requests and comparing the result). If the website is impacted, it'll also automatically fallback to GET and display this notice in your dashboard:

In rare cases the HEAD response gets broken AFTER the check creation (so initially it was working with HEAD and suddenly it returns an error but for you in the browser with GET request all is good). This is usually caused by some misconfiguration at the application server / reverse proxy / firewall level, by manually filtering some HTTP verb and accidentally breaking the http HEAD verb. This is considered a regression and so a downtime. You can verify if this is the case by trying some HEAD request on your endpoints (with curl you can do that with the curl -I flag)

The best option if this happen would be to repair this regression

You know precisely when it got broken from the downtime alert so you can probably find what change caused it. Alternatively if you understand the situation but prefer to ignore this broken behavior you can either:

1. Delete and re-create the check, this will trigger the automated detection again and thus the fallback to GET
2. Use the "contains" feature to search for a string in the page, this would also force a GET request as the body is needed.
3. Ask me to manually flag the website as non compliant HEAD implementation if you really want to keep the history and can't use the "contains" feature.

IP filtering

Another common scenario is that you (or your hosting provider) are doing IP filtering or running some kind of anti-DDoS / anti-Bot protection, which is blocking request from some or all of updown IPs.

In which case you obviously need to white-list updown requests in your protection, either by User-Agent (ideally) or by IP. You'll find more details on this here.

Created on October 17, 2023 · Suggest changes to this page