There can be a lot of reasons obviously so here we'll try to list the most common ones
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)
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:
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.