Odoo go-live crash after a module update what to do next

The crash after the update

You just pushed a new module update to your Odoo environment during go-live. Within minutes, users report the system is frozen, unresponsive, or keeps restarting. Worse, some transactions may be stuck or partially saved.

This is a common failure pattern: the update introduced a conflict, missing dependency, or bad code that crashes the Odoo worker process. The system doesn’t crash the whole server—just the Odoo service—so the database and other services remain intact. But users can’t work, and data may be at risk if changes were in flight.

What you see:

• Odoo web interface returns 502 Bad Gateway or shows a white screen
• Odoo logs show repeated tracebacks with Traceback (most recent call last)
• Database connections are still open, but the Odoo service won’t start

Why this happens

Odoo loads modules at startup. When a module update changes code that is already loaded or introduces a dependency conflict, the Odoo worker process crashes. The most frequent causes are:

• Version mismatch: the module expects a newer Odoo version than the one you’re running. For example, if you installed a module built for Odoo 16 on an Odoo 15 instance.
• Missing dependency: the module requires another module or Python package that isn’t installed. For example, a custom addon depends on account but account was disabled or not installed.
• Python error: a syntax error, undefined variable, or incorrect import in the new code. For example, a field name typo in a Python file under /odoo-custom-addons.
• Database schema conflict: the module ships a new field or model that conflicts with an existing one. For example, both modules define a field named x_studio_custom_id.

Note: Odoo doesn’t validate module compatibility during a standard update. It only checks when the module is installed, not when it’s updated. That’s why crashes often surface only after deployment.

Quick checks to confirm the crash cause

Step 1: Check the Odoo service status

Connect to your server via SSH and run:

sudo systemctl status odoo

What to look for: If the service is active (running), the crash may be intermittent. If it’s inactive (dead) or failed, the service crashed at startup.

Step 2: Inspect the Odoo log

Odoo writes detailed error messages to the log file. On most Linux systems, the log is at:

sudo tail -n 100 /var/log/odoo/odoo-server.log

What to look for:

• ModuleNotFoundError: a missing Python package or module
• ImportError: a Python import failure in a custom addon
• ValueError: a schema conflict or invalid field definition
• KeyError: a missing translation or XML ID

Example error:

2024-04-05 10:15:22,123 12345 ERROR odoo odoo.tools: Could not import custom/my_module/models/sale_order.py ImportError: cannot import name 'ResPartner' from partially initialized module 'res.partner'

This suggests a naming conflict in a custom module under /odoo-custom-addons.

Step 3: Verify module versions

List installed modules and their versions:

sudo -u odoo /usr/bin/odoo-bin --db_user odoo --db_password yourpassword --db_name yourdb --list-modules

Look for the recently updated module and compare its version with the Odoo version in use. If the module version is higher than your Odoo build, it’s likely incompatible.

How to recover without data loss

Your goal is to restore service quickly and safely. Avoid rolling back the database. Instead, disable the problematic module and restart Odoo. Then, fix the module or roll back the update.

Step 1: Disable the problematic module

Connect to the database as admin using psql or via Odoo’s web interface (if accessible). Run:

UPDATE ir_module_module SET state='uninstalled' WHERE name='your_problem_module' AND state='installed';

What this does: It marks the module as uninstalled without removing data or schema changes. Odoo will skip loading it on restart.

Tip: If you can’t access the web interface, use the command line:

sudo -u odoo /usr/bin/odoo-bin --db_user odoo --db_password yourpassword --db_name yourdb -u base,account,sale --stop-after-init

This loads only base modules and stops. It avoids loading the problematic module.

Step 2: Restart Odoo

Restart the Odoo service:

sudo systemctl restart odoo

Verify: The service should start cleanly. If it fails again, the issue may be in a dependency. Repeat Step 1 for the dependency module.

Step 3: Recover data in flight

If users were in the middle of a transaction when the crash happened, the database may have uncommitted changes. Odoo uses PostgreSQL transactions, so uncommitted changes are not visible to other users. However, if the transaction was partially written, you may need to:

• Check the PostgreSQL log for aborted transactions
• Review the Odoo log for any ROLLBACK messages
• Manually reconcile data if necessary (e.g., duplicate orders)

Note: If you’re unsure, contact your database administrator or Odoo support before making changes.

Fix the root cause before next go-live

Once service is restored, address the root cause to prevent recurrence. The fix depends on the symptom you found in the logs.

Case A: Version mismatch

• Upgrade your Odoo instance to match the module’s requirements. See Odoo pricing and implementation guides for version compatibility.
• If you can’t upgrade, find an older version of the module that matches your Odoo build.

Case B: Missing dependency

• Install the missing module or Python package. For example, if account is missing:

  sudo -u odoo /usr/bin/odoo-bin --db_user odoo --db_password yourpassword --db_name yourdb -i account --stop-after-init

• If the dependency is a third-party package, install it via pip:

  pip install package-name==version

Case C: Python error in custom addon

• Open the file under /odoo-custom-addons/your_module/models/your_model.py
• Fix the import or syntax error. For example, if you see:

  ImportError: cannot import name 'ResPartner'

  Change from res.partner import ResPartner to from odoo.addons.base.models.res_partner import ResPartner.

• Restart Odoo to verify the fix.

  sudo systemctl restart odoo

Case D: Schema conflict

• Identify the conflicting field or model name.
• Rename the field in the custom module or disable one of the modules causing the conflict.
• Run the update again:

  sudo -u odoo /usr/bin/odoo-bin --db_user odoo --db_password yourpassword --db_name yourdb -u your_module --stop-after-init

When to seek help

If any of the following occur, stop troubleshooting and escalate:

• Odoo still crashes after disabling the problematic module and restarting.
• PostgreSQL reports errors like deadlock detected or connection refused in the Odoo log.
• Data is corrupted or missing after the crash (e.g., orders missing, invoices unpaid).
• Error persists beyond 30 minutes of troubleshooting.
• You’re unsure how to proceed without risking data loss.

Where to get help:

• Odoo implementation team for version mismatches or deployment issues
• Custom addon developers for code-level issues in /odoo-custom-addons
• Integration partners if the issue involves third-party systems

What to provide: Share the Odoo log snippet, module name, Odoo version, and PostgreSQL version. Include a screenshot or copy of the error message.

Preventing crashes in future go-lives

Use a staging environment that mirrors production to test updates before go-live. Follow this checklist for every module update:

• Test in staging: Deploy the update in a non-production environment with realistic data volume.
• Check dependencies: Run pip list and /odoo-bin --list-modules to confirm all required modules and packages are installed.
• Validate schema changes: Use --update=all --stop-after-init to check for schema conflicts without affecting data.
• Monitor logs: Watch the Odoo log for warnings or errors during the update.
• Update documentation: Record the update steps and any rollback procedures in your runbook.

Pro tip: Use Odoo’s built-in --log-level=debug flag to capture more detail during testing:

sudo -u odoo /usr/bin/odoo-bin --db_user odoo --db_password yourpassword --db_name yourdb --log-level=debug -u your_module --stop-after-init

This helps catch subtle issues before they reach production.

Practical Next Step

Check your Odoo logs now

FAQ