How to Set Up Uptime Kuma for an Odoo Fleet (With the Right Monitor Settings)

Uptime Kuma is the self-hosted monitoring tool we use across our Odoo fleet. It is free, runs on a single Docker container, has a clean UI, and supports every alerting channel you actually need. This is the exact setup guide — including the Odoo-specific gotchas that will save you an hour of troubleshooting.

Installing Uptime Kuma

The fastest deployment is Docker. On a small dedicated monitoring VPS (1 vCPU, 1GB RAM is sufficient):

docker run -d   --name uptime-kuma   --restart unless-stopped   -p 3001:3001   -v uptime-kuma:/app/data   louislam/uptime-kuma:1

Access it at http://your-server-ip:3001. Create your admin account on first load. Then put Nginx in front of it with SSL — you do not want to run monitoring tooling over plain HTTP, especially if you are exposing it to the internet.

Alternatively, if you are already running Docker Compose on a server, add Uptime Kuma as a service in your compose file and use a Traefik or Nginx container as the reverse proxy. We maintain a dedicated monitoring server separate from the Odoo hosts for obvious reasons — if an Odoo server goes down and takes the monitoring with it, you have achieved nothing.

The Odoo-Specific URL Problem

The most common mistake when monitoring Odoo with Uptime Kuma: using the root URL https://yourodoo.com/ as the monitor target.

Odoo's root URL redirects to /web, which redirects to /web/login if the user is not authenticated, which returns a 200 OK with a login page. This means your monitor will report the instance as UP even when Odoo is in a broken state that still serves the login page — for example, when the database is unreachable but the web worker is still running, or when a deployment partially completed and left Odoo in an inconsistent state.

Use this URL instead: https://yourodoo.com/web/login

Set the expected keyword to something present on the login page, such as Login or Odoo. This way the monitor checks not just that the server responds, but that it responds with recognizable Odoo content. A 200 from a misconfigured Nginx default page will not trigger the keyword match and will correctly alert as down.

The Right Monitor Settings for Odoo

These are the settings we use for every Odoo instance in a fleet:

• Monitor type: HTTP(s) - Keyword
• URL: https://yourodoo.com/web/login
• Keyword: Login
• Heartbeat interval: 60 seconds (checking every 30s doubles traffic with minimal benefit for most setups)
• Retries: 3 (avoid false alerts from transient network hiccups)
• Retry interval: 20 seconds
• Request timeout: 30 seconds (Odoo can be slow to respond when under load; 10s causes false positives)
• Maximum redirects: 10 (Odoo uses several redirects from root to the login page)
• HTTP method: GET

The timeout setting is the one people get wrong most often. A 10-second timeout sounds reasonable but will generate false-positive alerts on any Odoo instance that occasionally takes 15 seconds to respond under load. This creates alert fatigue — the worst outcome for a monitoring system. Use 30 seconds and reserve alerts for genuine downtime.

Setting Up Email Alerts via Gmail SMTP

In Uptime Kuma, go to Settings → Notifications → Add Notification. Select Email (SMTP) and use these settings for a Gmail account:

SMTP Host: smtp.gmail.com
SMTP Port: 465 (SSL) or 587 (TLS/STARTTLS)
SMTP Username: your-gmail@gmail.com
SMTP Password: [App Password — not your regular Gmail password]
Secure: Yes (for port 465)
From: your-gmail@gmail.com
To: alerts@yourdomain.com

The critical detail: you must use a Gmail App Password, not your account password. Go to your Google Account → Security → 2-Step Verification → App passwords. Generate one for "Mail" and use that 16-character string as the SMTP password. Using your regular password will fail — Google blocks it even with 2FA disabled.

Monitoring the Full Fleet

For an 11-server Odoo fleet, we create one monitor per instance and group them using Uptime Kuma's Status Pages feature. A shared status page gives clients visibility into their infrastructure status without needing access to the Uptime Kuma admin panel.

We also add a secondary TCP port monitor on port 5432 (PostgreSQL) for each database server — this catches database-level issues that would not be caught by an HTTP check alone. If the HTTP monitor is up but the PostgreSQL TCP check is down, you have a database connectivity problem that Odoo may not have surfaced yet.

The full setup for an 11-server fleet takes about 45 minutes including SSL configuration and notification testing. Running without monitoring is not an option for production infrastructure. This is the simplest path to basic observability that actually works for Odoo.