What to monitor on an Odoo server

Why Odoo monitoring matters

When Odoo stops, a business stops invoicing, shipping and answering customers. Most outages are not sudden, though. Disks fill over weeks, databases grow over months, and a broken backup job can fail quietly every night until the day you need a restore. Monitoring turns those slow problems into a message you can act on during working hours, instead of a phone call at night.

A good setup answers three questions: is Odoo up, is it healthy, and will it still be healthy next month?

Odoo uptime: is it answering?

Internal health checks

Check from the server itself that Odoo answers HTTP requests, for example by requesting the login page every 30 to 60 seconds. Require two or three failures in a row before calling it down, so a single slow response does not wake anyone. A process supervisor such as systemd can restart Odoo if it crashes, but a restart that keeps happening is a problem in itself, so count restarts too.

External checks

A check from outside the server catches what internal checks cannot: an expired certificate, a DNS mistake, a firewall change or a server that is down entirely. Point an external uptime monitor at your public HTTPS address.

Server resources: CPU, RAM and disk

CPU and load

Short CPU spikes are normal when someone runs a big report. What matters is sustained use: if CPU stays above about 80% during working hours, users wait. Compare the load average with the number of vCPUs; a load that stays above the vCPU count means work is queuing.

Memory and swap

Watch available memory, not just used memory, because Linux uses free RAM as disk cache. Swapping on an Odoo server is a sign it needs more RAM or fewer workers. Our Odoo server sizing guide explains how to balance workers and memory.

Disk space

Running out of disk is one of the most common causes of Odoo outages, because PostgreSQL stops writing when the disk is full. Alert when free space drops below 10 to 15%, and watch what grows:

• The filestore, where Odoo keeps attachments;
• The database, including bloat from tables that need vacuuming;
• Log files, if rotation is not set up;
• Local backups, if old ones are not deleted.

PostgreSQL metrics for Odoo

• Connections compared with max_connections. Running close to the limit leads to "too many clients" errors.
• Long-running queries and transactions. A query running for minutes, or a session "idle in transaction", can block others and stop cleanup.
• Locks and waits. Users see these as screens that hang while another user or a scheduled action holds a lock.
• Database size over time, to plan disk and catch unexpected growth.

PostgreSQL exposes all of this through its statistics views, described in the PostgreSQL monitoring documentation. For fixing what you find, see our article on PostgreSQL tuning for Odoo.

Odoo-specific signals

Worker restarts and timeouts

With multiple workers, Odoo restarts a worker that goes over its memory or time limits and writes a line about it in the log. An occasional restart is the limits doing their job. Many restarts an hour point to a heavy report, an import or custom code that needs attention.

Errors in the Odoo log

Count ERROR and CRITICAL lines in the Odoo log over time. A sudden rise after a deploy is often the first sign of a broken module.

Scheduled actions

Odoo runs recurring work, such as email sending, reminders, subscription invoices and syncs, as scheduled actions. In the Scheduled Actions screen, check that important jobs have a recent last run. A job whose next run date is far in the past is stuck or failing.

The outgoing email queue

Emails that fail to send stay in Odoo's queue with a failed status. A growing queue usually means the mail server rejected a password change or a sending limit was hit, and customers are not getting their invoices.

Backups and certificates

• Backup success, every time. Alert on a failed backup and on a missing one: a backup that did not run at all is just as bad. Also check the size; a backup much smaller than usual is suspicious.
• Restore tests. Restore a backup to a test instance from time to time. Our Odoo backup strategy guide explains how.
• Certificate expiry. Alert a couple of weeks before a certificate expires, so a failed renewal can be fixed calmly. See our guide to Odoo HTTPS setup.

How to set useful Odoo alerts

• Alert on symptoms first: down, disk nearly full, backup failed, certificate expiring. These always need action.
• Use trends for the rest: CPU, memory and database size are better reviewed weekly on a chart than alerted on every spike.
• Send alerts where someone will see them, and agree who responds.
• Avoid alert fatigue. Every alert that fires without needing action trains people to ignore the next one.

Odoo monitoring in CloudPilot

CloudPilot includes the core of this checklist for every Odoo server it runs:

• Health checks every 30 seconds. The agent checks each instance's login page. After two failed checks in a row the instance counts as down, and CloudPilot restarts it, with a limit on how many restarts it tries.
• Alerts when an instance is down, restarted or recovered, when free disk space drops below 10%, when a certificate has less than 14 days left and when a backup fails. They appear in the dashboard, and are emailed on plans that include email alerts.
• Server charts for CPU, memory, disk, load and PostgreSQL connections over the last hour, day or week.
• PostgreSQL settings and query statistics on the server page.

Scheduled actions, the email queue and Odoo log errors are still worth checking inside Odoo itself. See Server monitoring and alerts for the dashboard, managed Odoo hosting for what CloudPilot looks after, and pricing for each plan.

Odoo server monitoring questions