Uptime Basics supports GET and HEAD requests for paid website monitors. Both methods test DNS, connection, TLS, redirects, response timing, and the HTTP status returned by the target.
New monitors use GET by default because it is handled more consistently by websites, CDNs, application frameworks, and bot-protection systems.
GET checks
A GET request asks the server for the selected URL using the method a browser commonly uses to load a page. Uptime Basics evaluates the response headers, status, timing, and, when you configure an expected-content marker, whether that text appears in the response. It does not render the page, execute JavaScript, or submit forms.
Choose GET when:
- you are monitoring a normal website page;
- the endpoint rejects or handles HEAD differently;
- a CDN or firewall treats HEAD as suspicious;
- the application route is designed around GET; or
- HEAD produces HTTP 400, 403, 405, 406, 500, or 501 responses that do not represent the site's real availability.
HEAD checks
A HEAD request asks for response headers without requesting the response body. It can reduce work for a compatible endpoint, but some sites do not implement it correctly or apply different security rules.
Choose HEAD only when you know the endpoint supports it and returns the same meaningful availability status as GET.
For common HEAD-rejection responses, Uptime Basics may try GET within the remaining timeout budget. This compatibility fallback does not change the request method saved in Monitor Settings.
Compare the methods
| Behavior | GET | HEAD |
|---|---|---|
| New-monitor default | Yes | No |
| Commonly supported by website routes | Yes | Varies |
| Requests the normal resource method | Yes | No body requested |
| Executes page JavaScript | No | No |
| Validates page content | No | No |
| Can follow redirects | Yes | Yes |
| Can use custom headers or Basic authentication | Yes | Yes |
Change the request method
- Open the monitor from Monitors.
- Open Monitor Tools.
- Select Monitor Settings.
- Choose GET or HEAD under Request method.
- Leave Follow redirects enabled unless the redirect response itself is what you intend to monitor.
- Select Save changes.
The method change applies to future checks. Earlier logs retain the result that was recorded at the time.
HTTP status and redirects
By default, responses below HTTP 400 are accepted. You can explicitly accept selected 400 through 599 responses for specialized endpoints.
When redirects are enabled, availability checks follow up to five HTTP 301, 302, 303, 307, or 308 responses. The redirect destination must also pass public-target safety validation. A missing Location header, unsafe destination, loop, or excessive redirect chain fails the check.
Troubleshooting
HEAD reports Down while the browser works
Switch the monitor to GET and compare the next results. Browsers normally use GET, while the server may reject HEAD.
GET returns 401 or 403
The endpoint may require authentication, an allowlisted request, or a custom header. Configure Basic authentication or approved custom headers only for a service you are authorized to monitor. Accept 401 or 403 only when that exact response represents healthy behavior.
The status is Up but page content is broken
HTTP monitoring confirms response availability, not visual rendering or business transactions. A page can return HTTP 200 while containing an application error. Content and browser-transaction monitoring are not currently provided.
Changing the method creates different latency
The application, CDN, or security layer may process GET and HEAD differently. Compare several successful checks rather than relying on one result.