HTTP(s) monitoring with Uptime Kuma: complete guide for UK websites

If Uptime Kuma had only one monitor type, it would be the HTTP(s) monitor. It is the workhorse of the product — the check you set up first and the one that covers the vast majority of day-to-day needs for any UK website, API or admin panel. This guide walks through every practical aspect of HTTP(s) monitoring in Uptime Kuma: the status codes that matter, the configuration options worth using, SSL certificate checking, authentication patterns, POST requests and the real-world conventions UK teams adopt in production. If you are new to Uptime Kuma itself, start with our plain-English introduction and come back here afterwards.

Why HTTP(s) monitoring is the baseline

Every public-facing website — whether it is a marketing brochure site, a WooCommerce shop, a SaaS dashboard or a headless API — speaks HTTP or its encrypted cousin HTTPS. An HTTP(s) monitor does roughly what a human does when they type a URL into a browser: it makes a request, measures how long the response takes, reads the status code and checks that nothing obviously went wrong. It is the closest automated approximation to "is my site working for customers right now?" that a monitoring tool can produce.

Other monitor types have their place. DNS monitors catch misconfigured records before they cause outages. Ping monitors confirm network reachability. Port checks verify that non-HTTP services are up. But the service your users actually consume almost certainly speaks HTTP, so HTTP(s) is what you monitor first. Everything else is supplementary.

The HTTP status codes that matter

Every HTTP response includes a three-digit status code. Understanding which codes mean "up" and which mean "down" is essential to configuring monitors that are neither noisy nor deaf.

Uptime Kuma's default is to treat any 2xx response as success. That is the right default for marketing sites and most APIs. The nuances that trip up real deployments are almost always in the 3xx and 4xx ranges.

Redirects (3xx). By default, Uptime Kuma follows HTTP redirects up to a limit of 10 hops and evaluates the final status code. If you want to monitor the redirect itself — for example, confirming that your old domain still 301s to the new one — you can disable redirect following and explicitly accept 301 as a success code.

Client errors (4xx). A 404 means the page does not exist. For a content page that is genuinely a problem and should be flagged as down. For a specific login-required page hit without credentials, a 401 or 403 is actually the correct response and should be treated as up. The Uptime Kuma UI lets you narrow the accepted range per monitor — this is one of the most underused features in practice.

Rate-limited responses (429). An HTTP 429 means the server is temporarily refusing to serve the request because you are making too many. If you are polling a public API, you can hit 429 without the API actually being down. Two good responses: raise the monitor interval, or configure 429 as a non-failure in the accepted-codes range.

Setting up your first HTTP(s) monitor

Once you are logged into Uptime Kuma and have created the admin account, add a new monitor from the dashboard. The form is straightforward; the fields that matter are roughly in this order.

• Monitor Type: HTTP(s). The default.
• Friendly Name: Whatever you want to call it in the dashboard. Pick descriptive names — "Checkout" is better than "example-com-checkout".
• URL: The full URL you want to monitor, including the scheme (https:// for anything public-facing in 2026).
• Heartbeat Interval: How often Uptime Kuma will check. The default 60 seconds is sensible for most UK sites.
• Retries: How many consecutive failures to tolerate before declaring the monitor down. The default of 0 is aggressive; 1-2 retries is usually better.
• Heartbeat Retry Interval: How long to wait between retries when in a failing state. 60 seconds is sensible.
• Request Timeout: How long to wait for a response before declaring failure. The default 48 seconds is generous; for most sites 15-30 seconds is more appropriate.
• Accepted Status Codes: The range you treat as success. Default is 200-299.
• Max. Redirects: How many 3xx hops to follow. Default 10.

For a typical UK marketing site or WooCommerce shop, the defaults produce a useful monitor. You can tighten and widen later as you learn what the site actually does.

Advanced options worth knowing

The basic fields are enough to watch most URLs. The advanced fields are what separate a generic monitor from one that catches real-world problems.

Ignore TLS Error. By default, certificate errors fail the monitor, which is usually what you want. The option to ignore is there for monitoring internal services with self-signed certificates; leave it off for anything public-facing.

Upside Down Mode. Inverts the up/down logic — the monitor is considered up when the request fails. Useful for confirming that a security block or firewall rule is still in force.

Request Method. GET is the default. You can select POST, PUT, PATCH, DELETE, HEAD or OPTIONS for endpoints that expect a specific verb.

Request Headers. A JSON object of headers to send. Most HTTP monitors work without any custom headers, but APIs behind a token, admin pages behind a specific user agent, or CDN-hosted sites requiring a specific Host header all live in this field.

Request Body. The body sent with POST, PUT or PATCH requests. JSON strings are the common case.

Authentication Method. None (default), Basic, NTLM, mTLS or OAuth 2.0 Client Credentials. For most public monitors you want None; authenticated admin pages use Basic or Bearer-token headers.

Proxy. Route the monitor through an HTTP proxy. Useful for monitoring services that are only reachable from a specific network.

Certificate expiry — the hidden part of HTTP(s) monitoring

An HTTP(s) monitor does not just check whether the site responds — it also, by default, reads the SSL certificate on the way in. Uptime Kuma records the certificate's expiry date and the chain of authority behind it. This matters because expired-certificate outages are among the most common self-inflicted downtime events for UK businesses, and they are almost entirely preventable.

Uptime Kuma will warn you as the expiry date approaches. The default warning thresholds are 14 and 7 days, which is generally enough time to react if something has gone wrong with Let's Encrypt auto-renewal. You can tune these thresholds per monitor if you need more notice — some teams go up to 30 days to allow for an administrator being on annual leave when the warning fires.

For wildcard certificates or certificates covering many subject alternative names, the same monitor handles the check transparently — you do not need multiple monitors just to watch the certificate across variants. Uptime Kuma reads the certificate served for the host specified in the URL field.

The certificate check also catches chain issues — an intermediate certificate missing, a mis-ordered chain, a certificate signed by an authority that major browsers no longer trust. These are rarer than simple expiry but when they happen they are often ignored by the monitoring that only looks at status codes, because the server itself happily returns HTTP 200 behind the broken chain. If you want to dig deeper into just certificate monitoring — which is worth doing independently for certificate-heavy estates — see our SSL certificate monitoring guide.

Handling authentication and custom headers

Many interesting URLs require authentication to respond usefully. The classic examples are admin panels, APIs behind a token, and internal dashboards. Uptime Kuma supports several patterns.

Basic authentication. Select Basic in the Authentication Method field and supply a username and password. Uptime Kuma encodes them into the Authorization header automatically. This is the easiest pattern and works with most admin-panel-style pages protected by HTTP basic auth at the reverse-proxy layer.

Bearer tokens. Not a native authentication method — instead, add an Authorization header in the Request Headers field. The JSON is something like {"Authorization": "Bearer xyz..."}. Rotate the token in Uptime Kuma when you rotate it in production.

API key in custom header. Many APIs expect X-API-Key or a similar. Add the header to Request Headers in the same way. Most public-cloud APIs — AWS, Cloudflare and similar — use this pattern.

Session cookies. Rarely worth the trouble to monitor. If you absolutely must, obtain a long-lived cookie manually and supply it via the Cookie header, but prefer Bearer tokens if the API supports them.

mTLS. For internal services that require mutual TLS authentication — common in enterprise environments — Uptime Kuma supports supplying a client certificate and key. The files live on the Uptime Kuma host and are referenced by path.

POST requests and body matching

Some endpoints do not respond meaningfully to a GET. Form submission endpoints, GraphQL APIs and several webhook receivers all expect POST. Uptime Kuma's HTTP(s) monitor handles this directly — select POST as the request method, paste your JSON payload into the Request Body field, and set the appropriate Content-Type header.

A common pattern for GraphQL is a tiny introspection query as the body: {"query": "{ __typename }"}. If the GraphQL service is up it returns a quick response; if it is down the monitor flags it. Gentler than running a real query, no harm to the backend, zero cost.

You can also match on the response body, not just the status code. For that, Uptime Kuma offers a Keyword monitor as a sibling type. In short: if status-code-only monitoring misses the case where the service returns HTTP 200 with an error payload, a keyword monitor catches it by looking for specific text in the response — or for its absence. The HTTP(s) monitor and the Keyword monitor are best thought of as complementary rather than rival; most serious UK deployments use both side by side, with the HTTP(s) monitor on the main URL and a Keyword monitor on the same URL verifying that the expected content is actually rendered.

One more HTTP-level nuance worth knowing: the response compression negotiated between Uptime Kuma and your server. Most modern servers return gzip-encoded responses by default; Uptime Kuma handles this transparently. If you are monitoring an older piece of infrastructure that does not negotiate compression cleanly, you may see slightly inflated response times and occasional content-length mismatches. Setting the Accept-Encoding header explicitly — usually to identity in difficult cases — removes the variable.

Intervals, timeouts and retries

These three numbers together define how sensitive and how responsive a monitor is. Getting them right is mostly a matter of matching the check behaviour to the service behaviour.

Interval is how often Uptime Kuma runs the check. Faster intervals detect outages sooner but produce more load on the monitored service and more rows in the database. 60 seconds is a sensible default for external-facing services. 20-30 seconds suits critical revenue-generating pages. Minutes-to-hours suits nightly batch processes via a Push monitor instead.

Timeout is how long Uptime Kuma waits for a response before declaring failure. It should be just longer than the worst acceptable response time, not longer. A site that normally responds in 500ms but sometimes takes 3 seconds wants a 10-second timeout — long enough to forgive the slow case, short enough to detect a genuinely hung request quickly.

Retries are how many consecutive failures to tolerate before flipping state. 0 retries means the first failure trips the alert — fine for critical services where you want to know immediately, noisy if your network is flaky. 1-2 retries filters out transient blips without losing much detection speed.

There is no universally correct combination. A sensible starting point: 60-second interval, 30-second timeout, 2 retries. Tune from there based on the false-positive rate you actually observe.

Common patterns for UK sites

Having covered the individual fields, here are the composite patterns we see working well in production for UK businesses.

Pattern 1: The homepage check. One HTTP(s) monitor per public domain, hitting the homepage, 60-second interval, 2 retries, 30-second timeout, 2xx accepted range, redirect following on. This is the bare minimum for any UK site.

Pattern 2: The four-corners check. In addition to the homepage, monitor (a) the login page, (b) a representative product or content page, (c) the API or admin endpoint behind authentication. This catches the cases where the homepage is up but a vital sub-system has failed — a surprisingly common failure mode.

Pattern 3: The checkout check. For e-commerce, monitor the full checkout path. A keyword monitor on the checkout page ensures the words "Payment" and "Total" appear; a separate JSON Query monitor hits the payment provider's health endpoint. Ticks the box for revenue-protection monitoring.

Pattern 4: The admin-panel check. A Basic-auth HTTP(s) monitor against your admin URL. If the admin panel falls over but the public site does not, your team finds out before a customer does.

Pattern 5: The partner-API check. For integrations with UK payment providers, CRM systems or ERPs, a tiny JSON Query monitor against their health endpoint tells you immediately if the partner is having trouble, before their outage becomes your incident ticket backlog.

Once your HTTP(s) monitors are in place, the next piece is routing the alerts somewhere a human will actually see them. Our SMTP notifications guide covers the most common email setup; team-chat integrations take another few minutes on top. If you are evaluating Uptime Kuma against commercial alternatives, our Uptime Kuma vs Uptime Robot comparison is the most relevant head-to-head for UK buyers.

Summary and next steps

HTTP(s) monitoring is the foundational capability of any monitoring tool, and Uptime Kuma does it well. Get the baseline pattern right — sensible interval, realistic timeout, a couple of retries to filter transient blips, accepted-codes range matched to what each URL actually returns — and the product will quietly watch your sites and APIs from day one. Add keyword or JSON Query monitors when a plain HTTP 200 is not sufficient signal. Enable certificate expiry warnings so the next renewal failure does not become a visible outage. Route the alerts into an inbox or team channel that humans actually read.

None of this is complicated. All of it is measurably valuable. The typical UK site goes from "we found out from a customer ticket" to "we got the alert 47 seconds after the outage started" on the first afternoon Uptime Kuma is set up properly.

A final pragmatic note. HTTP(s) monitors benefit significantly from being run against more than one URL per service, not from being run more frequently against a single URL. Two monitors at 60-second intervals give you better coverage than one monitor at 30-second intervals, because they test different parts of the stack and catch failure modes a single-URL monitor would miss. Spend your monitoring budget on breadth first, frequency second, and the false-positive rate stays low while real incident detection improves.

Frequently asked questions