---
title: "What Is Uptime Kuma? Setup and Monitoring Through a Proxy"
description: "Uptime Kuma is a free, open-source tool that checks your site at a set interval and alerts you when it goes down. We cover Docker setup and proxy settings."
url: https://proxynet.io/blog/uptime-kuma
date: 2026-09-25
author: "Enver Kaya"
category: "Use Cases, Integration"
lang: en
---

# What Is Uptime Kuma? Setup and Monitoring Through a Proxy

A small online shop in Konya runs Uptime Kuma on a VPS (a rented virtual server) in the same data centre as its web server, and the dashboard has been green for three days. On Monday the support inbox says otherwise: customers on mobile data cannot load the checkout page, and a dealer in Germany cannot reach the site at all. The fault is somewhere on the way to the site, such as a routing problem on one network or a geo-blocking rule set too wide. The monitor sat next to the site, so it saw none of this.

This guide covers what 99.9% uptime means in hours, what Uptime Kuma does, which monitor type to pick and how to install it with Docker. It then shows why checking from one place leaves a blind spot, how to send a monitor's checks through an HTTP or SOCKS5 proxy, and how much traffic that uses.

> **Note: Short answer**
>
> Uptime Kuma is a free, open-source monitoring tool that runs on your own server. It checks your site, API or port at a set interval (60 seconds by default), alerts you by email, Telegram or one of more than 90 notification services when a check fails, and keeps an uptime percentage. 99.9% uptime allows about 8 hours 45 minutes of downtime a year. Docker installs it with one command. HTTP monitors can check through a proxy, so you also see whether the site opens from a mobile network in Türkiye or from abroad.

## What is uptime, and what does 99.9% uptime mean?

Uptime is the share of time a service was reachable during a measured period; downtime is the rest. It is not the Linux `uptime` command, which shows how long one machine has been on. A 365-day year has 8,760 hours, and 99.9% leaves 0.1% of them, 8.76 hours, for downtime. Calculators that show 8 hours 45 minutes 57 seconds count a year as 365.25 days.

| Uptime | Downtime per year (365 days) | Per 30-day month | Per day |
|---|---|---|---|
| 99% | 87.6 hours | 7 h 12 min | 14 min 24 s |
| 99.5% | 43.8 hours | 3 h 36 min | 7 min 12 s |
| 99.9% | 8 h 45 min 36 s | 43 min 12 s | 1 min 26 s |
| 99.95% | 4 h 22 min 48 s | 21 min 36 s | 43 s |
| 99.99% | 52 min 34 s | 4 min 19 s | 8.6 s |

An uptime guarantee is this target written into a service level agreement (SLA). Google's SRE book describes two ways to measure it: the share of time a system was up, and the share of requests that succeeded ([Embracing Risk](https://sre.google/sre-book/embracing-risk/)).

## What is Uptime Kuma, and what is it for?

Uptime Kuma is a monitoring tool by Louis Lam, published under the MIT licence. You install it on your own server, open it in the browser and add monitors; each monitor is one address or service to check. The [project repository](https://github.com/louislam/uptime-kuma) had more than 90,000 stars in September 2026, when the current release was 2.5.5.

Unlike a hosted service, it keeps the check history and notification keys on your server and sets no limit on monitors. In return, you keep that server running, and it checks from where it runs. It also offers public **Status Pages**, **Maintenance** windows that pause alerts, and an interface in over 40 languages.

## How does Uptime Kuma check a site?

Every monitor repeats the same cycle:

1. **The interval runs out.** The **Heartbeat Interval** is 60 seconds by default. The request carries the User-Agent `Uptime-Kuma/2.5.5`, so you can find it in your server logs.
2. **It waits.** If no answer arrives within the **Request Timeout**, 48 seconds by default, the check fails.
3. **It reads the answer.** The status code must fall within **Accepted Status Codes**, `200-299` by default ([HTTP status codes](/blog/http-status-codes-web-scraping)). A Keyword monitor also searches the page for your word, case-sensitively.
4. **It retries.** With **Retries** above 0, a failed check is repeated at the **Heartbeat Retry Interval**. New monitors start at 0, so one lost packet sends an alert.
5. **It alerts.** When the retries run out, the monitor turns DOWN and the channels you added under **Settings > Notifications** get a message; when a check passes again, it turns UP.
6. **It records.** The monitor page shows uptime for 24 hours, 30 days and 1 year.

**Certificate Expiry Notification** is off on new monitors. Turn it on for HTTPS sites: Let's Encrypt began offering opt-in 45-day certificates in May 2026 and plans 64-day certificates by default from February 2027 ([Let's Encrypt](https://letsencrypt.org/2025/12/02/from-90-to-45/)), so renewals come round more often.

## Which monitor type should you choose?

Uptime Kuma 2.5.5 has about thirty monitor types. Most sites need these:

| Monitor type | What it confirms | Through a proxy? | When to choose it |
|---|---|---|---|
| HTTP(s) | The server answers with an accepted status code | Yes | A small health page |
| HTTP(s) - Keyword | The page contains a word you expect | Yes | Checkout, login |
| HTTP(s) - Json Query | An API answer holds the expected value | Yes | API endpoints |
| TCP Port, Ping, DNS | A port is open, a host answers, a record is right | No | Database, mail server, DNS |
| Push | A scheduled job reports that it ran | Not needed | Backups, cron jobs |
| Globalping | Ping, HTTP or DNS from a community probe | No, it runs from the location you type | Wide geography |
| UptimeRobot (hosted service, for comparison) | HTTP, keyword, port and ping from the service's servers | No; paid plans choose among four regions (September 2026) | Nothing to install |

HTTP(s) alone proves only that the server answered. Even a maintenance page or a broken template can answer 200 and count as UP. A Keyword monitor that looks for the label on the payment button catches both, and **Invert Keyword** alerts when a word such as "maintenance" appears. A health page is a short address your developer adds that answers "ok" when the application and database respond.

## Advanced: how do you install Uptime Kuma with Docker?

You need a Linux VPS or a home server with Docker, separate from the machine that runs the site. The command from the project README:

```bash
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2
```

- `-d` runs it in the background, and `--restart=always` starts it again after a crash or reboot.
- `-p 3001:3001` publishes the default port 3001.
- `-v uptime-kuma:/app/data` keeps the database in a Docker volume, which survives when the container is removed ([Docker volumes](https://docs.docker.com/engine/storage/volumes/)). The README says network folders (NFS) are not supported.
- `louislam/uptime-kuma:2` follows the 2.x series; on 25 September 2026 it pointed to 2.5.5.

With Docker Compose, download the official `compose.yaml` into an empty folder and run `docker compose up -d`; it keeps data in a local `./data` folder. Then open `http://your-server-ip:3001`, choose the language and a database (**SQLite** is enough for a small setup), create the admin account and click **Add New Monitor**. To update, pull the new image, remove the container and run the command again; the volume keeps your monitors.

Opening the dashboard on your own domain with HTTPS is a reverse proxy job for nginx or Caddy, which must pass the `Upgrade` and `Connection` headers for WebSocket; the [project wiki](https://github.com/louislam/uptime-kuma/wiki/Reverse-Proxy) has examples. The two proxy directions are compared in [Forward Proxy vs Reverse Proxy](/blog/forward-vs-reverse-proxy).

## What does monitoring from one place miss?

A monitor in the site's own data centre proves that the server works, not that customers can reach it. It misses:

- **A routing problem on one network:** customers of one provider cannot reach the site.
- **DNS that differs by region:** a wrong record on one DNS server affects only its users.
- **A geo-blocking rule set too wide:** a rule meant for one country also blocks another.
- **One CDN server returning errors:** a CDN serves the site from many servers, and only visitors sent to the broken one see errors.
- **Shared mobile IPs hitting a rate limit:** operators put many users behind one address ([What Is CGNAT?](/blog/what-is-cgnat)).

There are three ways to widen the view. The first is a second Uptime Kuma in another country. The second is the **Globalping** monitor type, added in version 2.1.0, which tests from community-hosted probes; its location field accepts a country, a city or a provider's name ([Globalping](https://globalping.io/)). Globalping allows 250 tests per hour without an account and picks from the probes online at that moment, so a given network may have no probe when you need one.

The third way is a proxy on the monitor: the check leaves through an exit in the country you choose, the idea behind a [localization test](/localization).

## How do you set a proxy on an Uptime Kuma monitor?

This covers the monitor's outgoing checks; the dashboard behind nginx is the reverse proxy case above. Proxy settings appear only on **HTTP(s)**, **HTTP(s) - Keyword** and **HTTP(s) - Json Query** monitors.

1. Go to **Settings > Proxies** and click **Set Up Proxy**.
2. Under **Proxy Protocol**, pick **HTTP** or **SOCKS v5 (+DNS)**. The list also has HTTPS, SOCKS, SOCKS v5 and SOCKS v4.
3. Under **Proxy Server**, enter `pr.proxynet.io` and port `8000` for HTTP, or the SOCKS5 port the endpoint builder shows.
4. Tick **Proxy server has authentication** and fill in **User** and **Password** (`user:pass` here). Copy the username from the Proxynet panel's endpoint builder; it carries the country, city and session ([Proxy Authentication](/blog/proxy-authentication-methods)).
5. **Set As Default** gives the proxy to new monitors, **Apply on all existing monitors** to current ones.
6. Save, then pick **No Proxy** or the proxy under **Proxy** on each monitor.

For a second country, click **Clone** next to the proxy and change the country in the username. "Checkout (Türkiye)" and "Checkout (Germany)" can then watch the same address.

The protocol decides where the site's name is looked up. **SOCKS v5** resolves the domain on the Uptime Kuma server; **SOCKS v5 (+DNS)** and **HTTP** let the proxy resolve it at the exit, so DNS is tested from the target country too ([SOCKS vs. HTTP Proxy](/blog/socks-vs-http-proxy)). To confirm the route, point a Keyword monitor with the proxy at a page that prints your country ([Is My Proxy Working?](/blog/how-to-test-a-proxy)).

The [Mobile Proxy](https://proxynet.io/mobile-proxy) pool has lines from Turkcell, Türk Telekom and Vodafone in Türkiye. You choose the country and city, not the operator; each check shows how the site behaves on a mobile network.

If the server cannot reach Telegram or another alert service, the `NOTIFICATION_PROXY` environment variable (since 2.0.0) sends most alerts through a proxy, though not email ([proxy environment variables](/blog/wget-proxy)).

## How much traffic does monitoring through a proxy use?

Residential and mobile proxies are billed per GB. At a 60-second interval, one monitor makes 43,200 checks in 30 days. Uptime Kuma downloads only the page's HTML, not images or scripts, but it opens a new connection through the proxy for every check, so each one repeats the TLS handshake, the exchange that sets up HTTPS encryption.

We measured this on 25 September 2026, sending Uptime Kuma's request (its headers, no compression) through a local HTTP proxy and counting the bytes in both directions:

| What the monitor loads | Per check | Every 60 s, 30 days | Every 300 s, 30 days |
|---|---|---|---|
| Small health page, 0.5 KB of HTML | 6.8 KB | 0.29 GB | 0.06 GB |
| Page with 120 KB of HTML | 127 KB | 5.5 GB | 1.1 GB |
| The same page, compressed with gzip | 36.5 KB | 1.6 GB | 0.32 GB |
| The same page, HEAD method | 7.5 KB | 0.32 GB | 0.06 GB |

For your own figure, take the page's uncompressed HTML size from the browser's developer tools, add 6-8 KB for the connection, then multiply by the checks per month and the number of monitors. To bring it down:

- **Watch a health page** instead of the home page.
- **Use HEAD** under **HTTP Options > Method**; it skips the page body, so Keyword monitors cannot use it.
- **Ask for compression** with `{"Accept-Encoding": "gzip"}` in the **Headers** field; keyword checks still work.
- **Lengthen the interval:** a monitor without a proxy every 60 seconds, proxy monitors every 2 to 5 minutes.

A [Residential Proxy](https://proxynet.io/residential-proxy) gives a home-connection exit in the country you pick. A rotating exit gives each check a new IP address, which makes response times jump; a [Sticky Proxy](https://proxynet.io/sticky-proxy) keeps one IP for 1-60 minutes.

## Use cases

- **Checkout seen from mobile data in Türkiye:** a Keyword monitor through a [Mobile Proxy](https://proxynet.io/mobile-proxy).
- **A dealer portal for partners abroad:** one monitor per dealer country ([localization testing](/localization)).
- **Your mobile app's API:** a Json Query monitor checked from a mobile network ([app testing](/app-testing)).
- **A partner API that accepts only listed IPs:** Uptime Kuma on a server with a fixed IP ([Static IP vs Dynamic IP](/blog/static-ip-vs-dynamic-ip)).
- **Changes in a page's content:** a different job, see [How to Monitor a Website for Changes](/blog/website-change-monitoring).
- **A one-off "is it down?" check:** see [This Site Can't Be Reached](/blog/this-site-cant-be-reached).

## Common mistakes

- **Installing the monitor on the server it watches.** When the server fails, the tool that should send the alert fails with it.
- **Leaving Retries at 0.** One lost packet at 3 a.m. wakes someone up; set 1 or 2.
- **Letting your own firewall block the monitor.** If it starts answering 403, allow the monitor's IP ([Access Denied error](/blog/access-denied-error)). Watch only sites you own or may check.
- **Plain SOCKS v5 for a location test.** DNS is still resolved on your server.
- **Turning on "Ignore TLS/SSL errors for HTTPS websites".** It also switches off the certificate expiry alert.
- **Running the container without a volume.** An update loses every monitor.

## Decision guide

| Need | Recommendation |
|---|---|
| Watch one site, install nothing | A hosted service; Uptime Kuma if the data should stay with you |
| Know the page opens with the right content | HTTP(s) - Keyword on checkout, Retries 1-2 |
| See the site as mobile users in Türkiye do | A monitor through a mobile proxy, HTTP or SOCKS v5 (+DNS) |
| Check from a customer's country abroad | A residential exit there; Globalping if a rough location is enough |
| Keep proxy traffic low | A health page, HEAD or gzip, a 2-5 minute interval |
| Watch a partner API with an IP allow list | A server with a fixed IP on the partner's list |
| Open the dashboard on your domain with HTTPS | A reverse proxy that passes WebSocket headers |

## Frequently asked questions

### Is Uptime Kuma free?

Yes, it is open-source software under the MIT licence. Your costs are the server it runs on and any proxy traffic.

### Which port does Uptime Kuma use?

Port 3001 by default. In `-p 8080:3001`, the first number is the port on your server and the second the port inside the container ([What Is Port 8080?](/blog/port-8080)).

### What is the difference between Uptime Kuma and UptimeRobot?

UptimeRobot is a hosted service with nothing to install; in September 2026 its free plan covered 50 monitors at a 5-minute interval. Uptime Kuma runs on your own server with no monitor limit, and you maintain that server.

### How much downtime does 99.9% uptime allow in a month?

43 minutes 12 seconds in a 30-day month, and about 43 minutes 50 seconds in an average calendar month.

### What is an uptime guarantee in an SLA?

It is the availability target in a provider's contract. Check the measurement period, what is excluded (such as planned maintenance) and the remedy, often a service credit.

### Can Uptime Kuma monitor from multiple locations?

Yes, though version 2.5.5 has no remote agents: a normal monitor checks from its own server. For more places, run copies elsewhere, use the Globalping monitor type or give each HTTP monitor a proxy in another country.

## Summary

An uptime percentage is only as accurate as the place it is measured from. Uptime Kuma installs with one Docker command; give checkout a Keyword monitor, set Retries to 1 or 2 and turn on the certificate alert. To see what your customers see, run the same monitor through an exit in their country, after working out the traffic. Our [proxy services](/proxy) page lists the exit types.