Khichdi InfoTech
Skip to content

Odoo Performance · intermediate · 9 min read

Monitoring Odoo in Production

Observability for live Odoo: RPC latency, worker health, PostgreSQL metrics, queue lag, cron duration, and alerting runbooks tied to business workflows.

Last reviewed 2026-07-30 · Estimated effort: 2–6 weeks typical implementation slice

Table of contents

Production monitoring for Odoo combines infrastructure signals (CPU, memory, disk I/O), application signals (worker restarts, request duration, error rate), database signals (connections, locks, slow queries), and integration signals (queue depth, cron duration, connector failures).

Alerts should map to runbooks: queue age above SLO triggers channel inspection; RPC p95 spike triggers slow query review; worker memory climb triggers leak suspicion in custom modules.

Baselines before Migration upgrades and seasonal peaks make regression obvious — compare the same dashboards week-over-week on named workflows, not only server uptime.

Uptime monitors that ping /web/login miss the failure mode where login works but confirm picking takes ninety seconds. Odoo needs workflow-aware observability plus integration lag metrics.

This article lists practical metrics, alert thresholds, and runbook hooks. Pair with diagnosis for first-incident response and with scaling when trends show sustained capacity pressure.

Infrastructure: CPU steal, memory pressure, disk latency, and network — correlated with Odoo worker count. Application: HTTP 5xx rate, RPC duration percentiles, worker recycle count, and longpolling stability.

Database: active connections, waiting locks, replication lag if used, and top queries from pg_stat_statements. Integration: oldest queue job age, jobs failed per hour, cron last run duration vs schedule.

  • RPC or HTTP p95 and p99 by route class
  • Worker memory RSS trend over 24 hours
  • PostgreSQL connections vs max_connections headroom
  • Queue pending count and age by channel

Structured logs with request id, db name, user login, and duration help tie user reports to code paths. Enable slow request logging at thresholds tuned to your SLO — avoid full debug SQL on production continuously.

Retain enough log history to compare pre- and post-deploy windows. Centralize logs if multiple workers make grep on single files impractical.

Every alert needs owner, severity, and first actions. Example: queue oldest job over thirty minutes — check channel concurrency, failed job message, recent deploy; do not restart all workers without evidence.

Suppress noisy alerts during known maintenance. Document expected cron spikes (nightly valuation) so on-call is not paged for normal batch load.

Executive view: order import lag, website p95, open incident count. Engineering view: slow query leaderboard, worker memory, deploy markers. Operations view: failed pick confirmations, report queue depth.

Review dashboards in weekly ops meetings during peak season — trends warn before hard failures.

  • Define SLOs for three critical workflows before enabling alerts.
  • Mark deploy and Migration events on all performance dashboards.
  • Page on queue age and RPC error rate; ticket on slow query trends.
  • Retain thirty days of metrics minimum for seasonal comparison.
  • Include connector vendor and custom module version in incident notes.
  • Run quarterly fire drills using historical incident scenarios.

  • !Monitoring only server ping while users suffer on specific actions.
  • !Alert thresholds copied from generic SaaS without Odoo baselines.
  • !Enabling verbose SQL log permanently and drowning disk I/O.
  • !No deploy markers — impossible to correlate regressions.
  • !Ignoring longpolling and bus disconnect metrics for live chat heavy teams.
  • !Closing alerts by muting instead of fixing rising queue lag trend.

Odoo production monitoring links metrics to workflows — RPC, database, workers, and queues — with runbooks operators can execute under pressure.

Next, review common mistakes teams make when interpreting or acting on those metrics.

Sample dashboard: RPC p95, queue age, slow queries, worker memory.

p95 response

watch

< 800ms

Failed jobs

on track

< 1%

DB CPU

watch

< 70%

Error rate

on track

< 0.5%

Alert fired to runbook steps to resolution loop.
1

Trigger

Business event starts the flow.

2

Execute

Operate in the system of record.

3

Validate

Check outcomes and exceptions.

4

Close

Reconcile and hand off.

Minimum viable Odoo monitoring checklist for AMC.
  • Owners named
  • UAT scripts signed
  • Rollback documented
  • Hypercare roster ready

Frequently asked questions

Which tools work well with Odoo?

Common stacks combine Prometheus or Datadog for infrastructure, PostgreSQL exporters, log aggregation (ELK, Loki), and custom queue metrics. Choose based on team skill — consistency beats tool perfection.

What should AMC support monitor daily?

Queue lag, failed crons, RPC error spikes, disk space, and backup success. Weekly review slow query trends and worker memory.

How do we monitor after Odoo upgrade?

Duplicate pre-upgrade dashboards, run parallel comparison for two weeks on Migration cutover — same workflows, same time windows.

Is synthetic monitoring useful?

Yes for login, shop category, and a scripted confirm-picking path on staging or production test company — complements passive metrics.

Building observability for Odoo?

Share your hosting stack, integrations, and past incidents — we will suggest metrics, alerts, and runbook priorities.

Business technology and software delivery