Odoo Server Monitoring: Prevent Downtime Before It Happens

Most Odoo administrators find out about problems one of two ways: a user calls to say "Odoo is down", or they happen to log in and see an error. Both are reactive. By the time someone notices, the business has already been disrupted.

Proper server monitoring means knowing about problems before — or at the very moment — they occur, so you can act before users are affected. This is not just for large enterprises; a single Odoo server for a 20-person company that goes down on a busy day can cost real money in lost productivity.

1. Disk usage
A full disk is the most common cause of Odoo failures. When disk fills up, PostgreSQL cannot write to the WAL (write-ahead log), Odoo cannot write filestore attachments, and the service crashes. Set an alert at 80% — not 95%. At 95% you are already in crisis mode.

2. Odoo HTTP health
Checking that the Odoo service is running (systemctl status) is not enough. The process can be running but returning 500 errors or stuck on a long-running query. A real health check is an HTTP GET to the Odoo login page and expecting a 200 response.

3. CPU and RAM usage
Spikes in CPU indicate heavy Odoo operations (month-end reports, large imports) or a runaway process. RAM over 90% triggers Linux OOM killer, which can kill the Odoo worker or even PostgreSQL.

4. PostgreSQL active connections
Odoo uses a connection pool. If active connections approach the max_connections limit, new requests will fail silently. Monitoring this catches pool exhaustion before it becomes an outage.

5. Agent connectivity
If the monitoring agent loses connection to the dashboard, you lose visibility entirely. An alert when the agent goes offline is the safety net that tells you monitoring itself has failed.

6. Uptime history
A 90-day uptime timeline lets you answer the question "how reliable has this server actually been?" and spot patterns — for example, daily 3 AM spikes that correlate with a heavy scheduled report.

Alerting is only valuable if you act on alerts. A monitoring system that sends 20 emails a day trains people to ignore all of them.

Effective alert configuration:

• Alert on thresholds, not on every check: disk at 80%, not "disk at 73.2%"
• Use a cooldown period: if disk is at 85% for 2 hours, send one alert — not one per check
• Route severity appropriately: disk warning → email; Odoo unreachable → email + Slack + PagerDuty
• Automatically resolve: when the condition clears, send a "resolved" notification so your team knows it is safe

ServerChest uses a 2-hour cooldown per alert type per server by default, so you get notified once and then again if the condition persists after the cooldown.

If you check health every 5 minutes, Odoo can be down for up to 5 minutes before you know. For a business processing online orders, that is unacceptable.

ServerChest's agent checks Odoo HTTP health every 60 seconds and reports uptime events immediately over the existing WebSocket connection — no polling delay. Backup progress is streamed in real time.

For disk and system metrics (CPU, RAM), a 60-second sample interval is the right balance between data resolution and server overhead.

ServerChest's agent runs on your Odoo server and continuously monitors:

• Odoo HTTP health (login page 200 check, every 60s)
• Disk usage with configurable threshold alert (default: 85%)
• CPU and RAM time-series (stored server-side for trend charts)
• PostgreSQL DB connection count
• Agent connectivity (reconnects automatically on network interruption)

All of this feeds into a dashboard with a real-time health overview, 90-day uptime timeline, and time-series charts for CPU, RAM, disk, and network I/O — without any configuration files to edit.