Uptime Kuma is a self-hosted monitoring system that you can deploy on your own VPS and use to check websites, APIs, and network services. It supports HTTP(S), TCP, keyword checks, public status pages, and various notification delivery methods.
In this guide, we will install Uptime Kuma using Docker, configure a domain and HTTPS, and then set up several types of monitoring: a standard HTTP website check, a TCP port availability check, and keyword-based monitoring of page content. We will also create a public status page and configure notifications through a universal webhook.
As a result, we will have a system that can:
- Monitor the availability of websites and APIs;
- Track service response times;
- Check whether TCP ports are open;
- Monitor whether the required text is present on a page;
- Publish service statuses on a dedicated status page;
- Receive notifications when failures occur.
At the end, we will separately simulate one of the services becoming unavailable, make sure the monitor switches to the Down state, and verify that a real alert is received. The Uptime Kuma interface itself will be available through the domain over HTTPS, while direct access to the application’s internal port will remain closed.
How Monitoring with Uptime Kuma Works
Uptime Kuma is a self-hosted monitoring system that runs on your own server and regularly checks the availability of external websites, APIs, and network services.
Unlike systems such as Prometheus, which collect a wide range of internal metrics, Uptime Kuma focuses primarily on availability checks: whether a website responds, whether a TCP port is open, whether a page contains the required text, and how long the response takes.
This makes it a convenient tool for basic uptime monitoring of small projects, APIs, internal services, and public websites.
What Uptime Kuma can do
Uptime Kuma supports multiple check types and lets you configure separate rules for different services.
You can use it to:
- Check websites over HTTP and HTTPS;
- Monitor API availability;
- Monitor open TCP ports;
- Check whether specific text is present on a page;
- Run DNS and ping checks;
- Track TLS certificate expiration;
- Create public status pages;
- Send notifications via webhook, email, and other integrations.
For each monitor, you can set a custom check interval, timeout, retry count, and notification method.
Uptime Kuma also stores availability and response time history, so the interface shows not only the service’s current state but also its behavior over the past hours and days.
Types of checks we will use
In this guide, we will configure three types of monitoring.
The first is a standard HTTP(S) check: https://example.com
Uptime Kuma will send requests at regular intervals and consider the service available if the server returns a successful response.
The second option is a TCP check. It verifies that a specific port on the server is accepting connections.
For example:
Host: example.com
Port: 443
This type of check is useful when you need to monitor the availability of a specific network service rather than a web page.
The third option is keyword monitoring. In this case, Uptime Kuma not only checks the HTTP response but also looks for the specified text in the page content.
For example: Keyword: Application is running
If the page continues to respond but the expected string disappears, the monitor may switch to the Down state. This helps identify situations where the web server is technically running, but the application is returning the wrong page or incorrect content.
How the monitoring setup will be structured
Uptime Kuma will run in a Docker container on a separate VPS.
Simplified diagram:
Uptime Kuma itself will listen on port 3001 inside the VPS.
For external access to the dashboard, we will configure Nginx:
In the final configuration, we will not use direct public access to port 3001. Users will access the interface only through the domain over HTTPS.
Preparing the VPS
Before installing Uptime Kuma, we will prepare the system and install Docker. This example uses Ubuntu.
Updating the system
First, update the package index: sudo apt update
Install the available updates: sudo apt upgrade -y
After that, you can check the system version: lsb_release -a
And the available resources:
free -h
df -h
For a small number of monitors, Uptime Kuma does not require significant resources, so a dedicated high-performance VPS is usually not necessary.
The application’s core data will be stored in a Docker volume, so the configuration and monitoring history will be preserved when the container is updated or recreated.
Installing Docker and Docker Compose
Install Docker from the standard Ubuntu repository: sudo apt install -y docker.io docker-compose-v2
Start Docker and enable it to start automatically: sudo systemctl enable –now docker
Check the status: sudo systemctl status docker –no-pager
Check the versions:
docker –version
docker compose version
After that, the VPS is ready to run Uptime Kuma via Docker Compose.
Ports required by Uptime Kuma
During setup, we will use the following ports:
| Port | Purpose |
| 22 | SSH access to the VPS |
| 80 | HTTP and Let’s Encrypt certificate issuance |
| 443 | HTTPS access through Nginx |
| 3001 | Internal Uptime Kuma web interface |
Port 3001 is required by the application itself, but in the final configuration it should not be directly accessible from the internet.
From outside, users will connect only to:
and Nginx will forward requests to the local container.
Why You Should Not Leave the Uptime Kuma Port Publicly Accessible
Uptime Kuma includes an administrative interface, a list of monitored services, incident history, and notification settings.
For this reason, you should not leave port 3001 open to the entire internet without an additional reverse proxy.
In addition, exposing the application’s internal port directly makes it harder to configure HTTPS and a domain later.
A better setup is: Internet → Nginx :443 → Uptime Kuma :3001
In this setup, Nginx handles external HTTPS requests, while the container itself listens only on localhost. The ideal architecture is for the service to be accessible only from the administrators’ external IP addresses or through a tunnel, but we will use a simplified option.
This approach reduces the number of directly accessible services and allows the TLS certificate to be managed centrally.
Now let’s deploy Uptime Kuma itself.
Installing Uptime Kuma with Docker
Creating the application directory
Create a separate directory: sudo mkdir -p /opt/uptime-kuma
Change to that directory: cd /opt/uptime-kuma
The Docker Compose file and application data will be stored separately from the other VPS services.
Creating a Docker Compose configuration
Create the file: sudo nano docker-compose.yml
Add the following configuration:
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
– “127.0.0.1:3001:3001”
volumes:
– uptime-kuma-data:/app/data
volumes:
uptime-kuma-data:
Note the following line: 127.0.0.1:3001:3001
It publishes the container port only on the VPS loopback interface.
This means http://PUBLIC_IP:3001 will not be accessible from the Internet, but Nginx will be able to access http://127.0.0.1:3001 locally.
Volume:
uptime-kuma-data
will store the database, settings, monitor list, and Uptime Kuma history independently of the container lifecycle.
Starting the Uptime Kuma Container
Start the application: sudo docker compose up -d
Docker will download the image and create the container.
Check the list of containers: sudo docker ps
The output should show uptime-kuma with a status of Up.
If necessary, you can view the logs: sudo docker logs uptime-kuma –tail 50
Checking the Container Status
Use a more concise command to check the container: sudo docker ps –filter name=uptime-kuma
Expected result:
CONTAINER ID IMAGE STATUS
… louislam/uptime-kuma:1 Up …
Now make sure the application responds locally: curl -I http://127.0.0.1:3001
You can check the local binding with the following command: sudo ss -lntp | grep 3001
The output should include the address: 127.0.0.1:3001
This confirms that Uptime Kuma is running in the container and is already accessible locally, but its internal port is not published directly to the internet.
Initial Uptime Kuma Setup
After starting the container, you can proceed with the initial setup of the web interface. At this stage, we will create an administrator account, familiarize ourselves with the dashboard, and configure the basic settings required for further monitoring.
Creating an administrator account
Because Uptime Kuma is currently available only locally at 127.0.0.1:3001, you can temporarily use an SSH tunnel for the initial login or set up Nginx first. For this exercise, it is more convenient to access it through a local tunnel and configure the domain and HTTPS later.
On your local computer, run: ssh -L 3001:127.0.0.1:3001 -i “C:\Path to your key\Key name.pem” ubuntu@Your_IP
After the connection is established, open the following in your browser: http://127.0.0.1:3001
On first launch, Uptime Kuma will prompt you to create an administrator account.
Enter:
Username: admin
Password: a strong password
It is best to use a password that is different from your SSH password, cloud console password, or passwords for other services.
After the account is created, the main Uptime Kuma dashboard will open.
Dashboard Overview
The home page displays a list of monitors and their current status.
The list is currently empty because no checks have been created yet. Later, it will show the following states:
Up
Down
Pending
Maintenance
For each monitor, Uptime Kuma also shows the response time, event history, and uptime percentage.
Main interface elements:
- Dashboard — a list of all monitors;
- Add New Monitor — create a new check;
- Status Pages — public status pages;
- Settings — notifications and global settings;
- Maintenance — maintenance windows.
After several checks have been created, the Dashboard will become the main workspace for monitoring services.
Configuring basic settings
Before creating monitors, you can open Settings and check the basic settings.
The first things to configure are:
- Time zone;
- Interface language;
- Date and time format;
- Notification settings;
- External URL, if it is used in messages.
If the VPS operates in one time zone and the administrator is in another, the correct time zone is especially important for event logs and notification trigger times.
You can leave the remaining settings at their defaults and return to them after configuring the monitors.
Creating an HTTP Website Check
First, we will create a standard HTTP(S) monitor. It will regularly send requests to the website and verify its availability.
Adding an HTTP(S) Monitor
In the Dashboard, click Add New Monitor
In the Monitor Type field, select HTTP(s)
Enter a descriptive name, for example: Main Website
In the URL field, enter the website address: https://example.com
Uptime Kuma will send an HTTP request and evaluate the response it receives.
For a standard website, you can keep the default method: GET
If the URL responds correctly, the monitor will switch to the Up state after it is saved.
Configuring the check interval and timeout
You can set a custom check frequency for each monitor.
For example: Heartbeat Interval: 60 seconds
This means that Uptime Kuma will check the site once per minute.
For a test environment, you can choose a shorter interval, such as 20 seconds
This is useful when testing failure scenarios, because you do not have to wait long for the status to change.
You can also configure:
Retries
Timeout
Accepted Status Codes
For example, if the service is considered operational only when it returns 200, you can restrict the accepted status codes.
In most standard scenarios, it is sufficient to keep the default range of successful HTTP status codes.
Checking website availability and response time
After saving, the monitor will appear on the Dashboard.
After a few seconds, Uptime Kuma will make the first request and display: Up
The response time will also be displayed, for example: Response: 120 ms
The longer the monitor runs, the more data will be available in the history.
Open the monitor card. It shows:
- Current status;
- Response time;
- Uptime percentage;
- Heartbeat history;
- Recent events.
However, an HTTP check alone is not enough for every scenario. Sometimes you need to check whether a specific port is reachable or verify that a web page contains the expected text.
To do this, we will create two more monitors.
Creating TCP and keyword checks
Checking TCP Port Availability
Click Add New Monitor and select TCP Port as the type.
Name the monitor: HTTPS TCP
Set the hostname to: example.com
Port: 443
You can leave the interval the same as for the HTTP check.
After saving, Uptime Kuma will attempt to establish a TCP connection to the specified address.
If the port accepts connections, the monitor is shown as: Up
This type of check is suitable for databases, SSH, SMTP, and other network services when the TCP port itself needs to be available.
Creating a keyword monitor
Now let’s create a page content check.
Click Add New Monitor and select the HTTP(s) – Keyword type.
Name: Website Keyword
URL: https://example.com
In the Keyword field, enter the text that must be present on the page.
For example: Example Domain
Uptime Kuma will send an HTTP request and also check the returned content.
If the site responds but the required text is missing, the monitor will be considered down.
This is useful in situations where the web server returns HTTP 200 but displays a placeholder, an application error, or incorrect content instead of the normal page.
Checking for the required text on the page
After saving the keyword monitor, wait for several heartbeats.
If the specified string is present in the response, the status will become: Up
The Dashboard should then display three checks at the same time:
| Main Website | Up |
| HTTPS TCP | Up |
| Website Keyword | Up |
This set already covers three different levels of monitoring: web service availability over HTTP, whether the network port is open, and whether the page content is correct.
Configuring Notifications
One of the key advantages of Uptime Kuma is that it can do more than just record incidents in the panel: it can immediately send a notification to an external channel. This lets you learn about an issue without constantly monitoring the Dashboard.
In this guide, we will use a universal webhook. This option works for most scenarios because the event can be sent to your own service, a messenger, an automation workflow, or another endpoint that can receive HTTP requests.
Choosing a Notification Delivery Method
Uptime Kuma supports multiple notification methods. Depending on the version and configuration, you can use email, webhooks, and other integrations.
For a universal setup, a webhook is more convenient because it is not tied to a specific email provider or messaging app.
The logic is as follows:
When a monitor’s status changes, Uptime Kuma sends an HTTP request to the specified URL.
This mechanism can be used for both a simple test endpoint and a custom notification handler.
Configuring a universal webhook
Open the Uptime Kuma settings and go to the notifications section.
Create a new notification and select the type: Webhook
Set a descriptive name, for example: Main Webhook
In the URL field, enter the endpoint that will receive requests: https://webhook.example.com/uptime
For testing, you can use your own temporary webhook endpoint that displays incoming HTTP requests.
If the endpoint supports POST requests with JSON, keep the corresponding method and request body format.
If needed, you can also configure:
- HTTP headers;
- Authorization;
- Content-Type;
- Custom JSON body;
- Additional request parameters.
If the endpoint requires a token, it is best to pass it in the authorization header rather than adding it directly to the URL.
Assigning a Notification to Monitors
A notification you create is not used automatically. You need to assign it to the required monitors.
Open, for example: Main Website
Open it for editing and, in the notifications section, enable: Main Webhook
You can assign the notification to the following in the same way:
HTTPS TCP
Website Keyword
If a single notification is used for all checks, Uptime Kuma can report failures for each of these services via one webhook.
For a small project, this is sufficient. In a larger infrastructure, you can create separate notification channels for different groups of services.
Sending a Test Notification
Before using a webhook for live monitoring, make sure it works.
In the notification settings, use the test send feature.
Uptime Kuma will send a request to the specified endpoint. If the configuration is correct, the interface will confirm that the notification was sent successfully.
The webhook endpoint should also receive an actual incoming request from Uptime Kuma.
Sending a test notification is important because it allows you to verify the URL, request method, and authentication before an actual outage occurs.
Creating a Public Status Page
Uptime Kuma lets you create a separate public status page for your services. It can be used for customers, employees, or project users who do not need access to the administrative monitoring dashboard.
The Status Page displays only the selected monitors and their current status.
Creating a status page
Open the Status Pages section and create a new page.
Specify a slug, for example: services
It will be used in the page URL.
After connecting a domain, the address might look something like this: https://status.example.com/status/services
You can make the name more descriptive: Service Status
Adding Monitors to the Status Page
Now add the checks you created earlier to the page.
For example:
Main Website
HTTPS TCP
Website Keyword
You can combine them into a single group: Production Services
After saving, the Status Page will display the status of each selected monitor.
If all services are operating normally, the user will see them in the Operational state or a similar status in the interface.
If a failure occurs, the corresponding page element will update its status automatically.
Configuring the page name and description
To make the Status Page clear to users, add a name and a brief description.
Example: Service Status
Description: Current availability of websites and API services.
If necessary, you can also change:
- Page title;
- Displayed groups;
- Appearance;
- Monitor order;
- Event history visibility.
Do not include internal addresses, administrative URLs, or other internal-use information on the public page.
Checking the Public Status Display
After saving, open the Status Page in a separate browser tab.
Make sure it displays all selected services:
Main Website
HTTPS TCP
Website Keyword
and their current status.
At this stage, all three monitors should be up.
The public page is updated based on the same checks performed by Uptime Kuma, so users can see the current service status without access to the administrative Dashboard.
Simulating a Failure and Verifying Alerts
After configuring monitoring and the webhook, you need to test the entire workflow end to end: from the failure occurring to receiving the notification.
For the test, it is best to use a controlled method that can be quickly rolled back.
How to safely simulate service unavailability
Do not intentionally take down someone else’s site or generate load on an external resource. It is much safer to use a separate test service, temporarily change the address of one of the monitors, block its IP address with a firewall, or map its hostname in the hosts file to a deliberately incorrect IP address.
For example, for a TCP monitor, you can temporarily specify a port where the service is not running:
Host: example.com
Port: 65530
Another option is to create an additional HTTP monitor with a deliberately unavailable URL: http://127.0.0.1:65530
After you save the configuration, Uptime Kuma will start running checks and encounter a connection error.
To speed up the test, you can temporarily use a short heartbeat interval and a small number of retries.
Monitor transition from Up to Down
After several failed checks, the monitor will change state.
First, Uptime Kuma records failed heartbeats, and then the status becomes: Down
The Dashboard usually also displays the reason:
Connection refused
Timeout
DNS error
or another failed check result.
A red segment corresponding to the downtime period will appear on the history chart.
This makes it possible to distinguish a brief response delay from a confirmed outage.
Receiving an actual notification
When the monitor enters the Down state, Uptime Kuma triggers the linked notification.
In our case, a request will be sent to: Main Webhook
The webhook endpoint should receive a new incoming request for an actual event, not a test event.
The message will contain information about the monitor and its state change.
This test confirms that the entire chain is working:
This is more important than simply using the Test button, because it shows that the notification is actually linked to the monitor and is triggered by a real state change.
Restoring the Service After the Test
After receiving the notification, restore the monitor to the correct settings.
For example, if an incorrect port was temporarily used for the TCP check, set it back to: 443
After the next successful check, the monitor will return to: Up
Uptime Kuma will record the service recovery and, if the notification settings allow it, send another event indicating that the service has returned to an operational state.
After the test, make sure the Dashboard once again shows the normal status of all active monitors.
In this way, we verified not only the monitoring itself, but also the full incident handling cycle: failure detection, status change, notification delivery, and subsequent recovery.
Connecting a Domain and Enabling HTTPS
After configuring monitors, notifications, and the Status Page, you can make Uptime Kuma available on a dedicated domain. To do this, we will configure DNS, install Nginx as a reverse proxy, and issue a TLS certificate with Certbot.
In the final setup, Uptime Kuma will continue to run inside Docker on local port 3001, while all external requests will go through Nginx.
Creating a DNS Record for Uptime Kuma
First, choose the subdomain that will be used for the monitoring dashboard.
For example: status.example.com
In the domain’s DNS panel, create an A record:
Type: A
Name: status
Value: 203.0.113.10
Here, 203.0.113.10 is used as an example public VPS IP address.
After DNS has been updated, you can verify name resolution with nslookup status.example.com or dig +short status.example.com.
The VPS IP address should be returned in the response.
Until the DNS record resolves correctly, issuing a TLS certificate through Let’s Encrypt will fail.
Configuring Nginx as a reverse proxy
Install Nginx: sudo apt install -y nginx
Create a separate configuration file: sudo nano /etc/nginx/sites-available/uptime-kuma
Add the following:
server {
listen 80;
server_name status.example.com;
location / {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
The parameter proxy_pass http://127.0.0.1:3001;
forwards incoming requests to the local Uptime Kuma container.
Enable the configuration: sudo ln -s /etc/nginx/sites-available/uptime-kuma /etc/nginx/sites-enabled/uptime-kuma
Check the syntax: sudo nginx -t
If the check succeeds, apply the changes: sudo systemctl reload nginx
After that, Uptime Kuma should be available over HTTP at: http://status.example.com
Issuing a TLS Certificate with Certbot
Install Certbot and the Nginx plugin: sudo apt install -y certbot python3-certbot-nginx
Request a certificate: sudo certbot –nginx -d status.example.com
Certbot will check that the domain is reachable, issue a Let’s Encrypt certificate, and update the Nginx configuration.
After the process completes successfully, the interface will be available at: https://status.example.com
Check the configuration: sudo nginx -t
Check the Nginx status as well: sudo systemctl status nginx –no-pager
Checking HTTPS Access to Uptime Kuma
Open the following URL in your browser: https://status.example.com
The Uptime Kuma dashboard should load, and the browser should indicate a valid HTTPS connection.
You can also check the headers: curl -I https://status.example.com
The service’s HTTP status should be returned via Nginx.
At this point, Uptime Kuma is available at a proper public address, and the internal Docker port is not accessed directly by users.
Securing Uptime Kuma
After publishing it through Nginx, it is important to ensure that external users cannot bypass the reverse proxy and access Uptime Kuma directly on port 3001.
Blocking Direct Access to Port 3001
In Docker Compose, we used:
ports:
– "127.0.0.1:3001:3001"
This means Docker publishes the port only on the VPS loopback interface.
Check it: sudo ss -lntp | grep 3001
Expected address: 127.0.0.1:3001
If the address is 0.0.0.0:3001 or *:3001 instead, update the Docker Compose configuration and recreate the container.
After making the change:
sudo docker compose down
sudo docker compose up -d
Dashboard access only through Nginx
After restricting the port, the working setup looks like this:
In this case, a request to http://203.0.113.10:3001 should not open the interface.
Locally, Uptime Kuma will continue to respond: curl -I http://127.0.0.1:3001
This confirms that the application is accessible to the reverse proxy but is not exposed directly.
Checking Open Ports on the VPS
List all listening TCP ports: sudo ss -lntp
For the final configuration, the following ports typically need to be exposed externally:
22
80
443
Port 3001 should be bound only to localhost.
If UFW is used, external access can be restricted as follows:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Check the status: sudo ufw status
There is no need to open 3001/tcp separately.
Updating the Container Without Losing Data
Uptime Kuma configuration and history are stored in the Docker volume: uptime-kuma-data
Therefore, the container can be recreated without deleting any data.
Before updating, go to the project directory: cd /opt/uptime-kuma
Pull the latest image: sudo docker compose pull
Recreate the container: sudo docker compose up -d
Check it: sudo docker ps –filter name=uptime-kuma
Because the volume remains the same, monitors, user settings, and history are preserved.
Before any update, it is also a good idea to back up the Docker volume data and the application directory, or alternatively, take a VPS snapshot.
Maintaining Monitoring
After deployment, the main tasks are to monitor logs, update the container, and add new services as needed.
Viewing Docker Container Logs
If Uptime Kuma is not working properly, start by checking its logs: sudo docker logs uptime-kuma –tail 100
To view new messages in real time: sudo docker logs -f uptime-kuma
The logs may show startup errors, network issues, database errors, and other application messages.
You can check the container status with: sudo docker ps –filter name=uptime-kuma
Restarting Uptime Kuma
To restart the container normally: sudo docker restart uptime-kuma
If you are using Docker Compose:
cd /opt/uptime-kuma
sudo docker compose restart
Then check: sudo docker ps
Also check local availability: curl -I http://127.0.0.1:3001
Adding New Websites and APIs
For a new service, creating a separate monitor is usually sufficient.
For a website, use HTTP(s).
For an API, you can check a specific endpoint: https://api.example.com/health
If the API must return specific text or a JSON fragment, you can use a keyword check.
For a network service, use a TCP monitor with the hostname and port specified.
To keep the Dashboard structure clear, it is best to use a consistent naming convention, for example:
Production – Website
Production – API
Production – PostgreSQL
Staging – Website
As the number of monitors grows, this makes it easier to navigate the list and group services on the Status Page.
What to do if a monitor reports a false Down status
Sometimes a service is working normally, but Uptime Kuma periodically records it as Down. The cause is not necessarily in the application itself.
Start by checking:
- Whether the URL and port are correct;
- DNS resolution;
- HTTP status code;
- Request timeout;
- Number of retries;
- Network reachability from the VPS itself, including firewalls and other security controls on the site being checked;
- TLS certificate;
- Whether a keyword is configured for the relevant check.
For example, you can repeat an HTTP check directly from the VPS: curl -I https://example.com
For a TCP service: nc -vz example.com 443
If manual requests also occasionally time out, the problem is not with Uptime Kuma but with the connection or the monitored service itself.
If the service responds consistently but individual heartbeats are still missed, you can increase the timeout or the number of retries. However, avoid setting these values too high; otherwise, Uptime Kuma will take too long to recognize a genuinely unavailable service as down.
For a keyword monitor, also make sure the target text is actually present in the HTTP response. Changes to the site content can cause a Down status even if the server itself continues to return code 200.
A step-by-step check of the monitor settings and a manual request from the VPS usually make it easy to determine whether the event is a real outage or a false positive.
Conclusion
Uptime Kuma lets you deploy a convenient monitoring system for websites, APIs, and network services on your own VPS. Unlike more complex monitoring stacks, most configuration is done through the web interface: you simply create the required monitors, define the check conditions, and configure notifications.
In this guide, we installed Uptime Kuma using Docker, configured HTTP, TCP, and keyword checks, created a public Status Page, and connected a universal webhook. We then simulated a failure separately and verified that the monitor did indeed switch to the Down state and that the external endpoint received an actual notification.
To expose the interface, we used Nginx as a reverse proxy with HTTPS. The internal Uptime Kuma port remained bound to localhost, so users do not need to access port 3001 directly. This approach aligns with the project’s recommendations: use a reverse proxy to expose Uptime Kuma securely, and take WebSocket support into account when proxying.
The resulting setup is suitable for small websites, APIs, internal services, and personal side projects. As the infrastructure grows, you can add new monitors, separate Status Pages, and additional notification channels.
FAQ
Can Uptime Kuma be used without Docker?
Yes. The project can be run in several ways, but Docker remains one of the primary and most convenient installation options. The official documentation separately covers Docker deployment and container updates.
Which services can be monitored with Uptime Kuma?
Uptime Kuma supports different monitor types, including HTTP(S), TCP, and other checks. For a typical web project, an HTTP(S) monitor for the website or API, a TCP check for the relevant port, and an additional page content check are usually sufficient.
Why use a keyword check if the website is already monitored via HTTP?
A standard HTTP check shows that the server returned an acceptable HTTP status code. However, this does not always mean the application is working correctly.
For example, the server may return a 200 status code while displaying a placeholder or the wrong page. A keyword monitor also checks for the expected content and helps detect this type of failure scenario.
Do I need to expose port 3001 to the internet?
No, if Uptime Kuma is published through a reverse proxy. The official documentation recommends using Nginx, Apache, or another reverse proxy to publish the interface securely. In this case, the application port itself can be bound to localhost.
Why are the Upgrade and Connection headers needed for Nginx?
Uptime Kuma uses WebSocket, so the reverse proxy must correctly handle WebSocket connections. The official documentation specifically notes that the Upgrade and Connection headers are required.
Can notifications be sent via channels other than a webhook?
Yes. Uptime Kuma supports many notification providers. The official wiki lists the built-in notification methods and integrations via Apprise; a webhook is a general-purpose option for HTTP POST integrations.
Why test an actual Down state separately if the Test button already works?
The Test button checks only the notification channel itself. It confirms that Uptime Kuma can send a request to the webhook, but it does not validate the full monitoring chain.
Simulating a failure also confirms that the monitor actually detects the problem, changes state, and then triggers the linked notification.
Can I create multiple public Status Pages?
Yes. Status Page is a separate Uptime Kuma feature, so you can create pages for different groups of services and display only the relevant monitors on each one.
What happens to the settings after recreating the Docker container?
If the Uptime Kuma data is stored in a persistent Docker volume, recreating the container itself should not delete the configuration. The official upgrade instructions also use the persistent volume /app/data when removing the old container and starting a new one.
