View Logs
Logs help you understand what a deployment is doing, whether it is a build that failed or a running instance throwing errors. Skysize shows logs per deployment.
Open the logs for a deployment
- Open your project and go to the Deployments tab.
- Find the deployment you want to inspect and click View Logs (or open the deployment to reach its detail page).
- On the deployment detail page, open the Logs tab.
The build and install output streams here while a deployment is running, and the logs remain available afterwards.
Choose which log to read
The Logs tab has a Log file selector. Use it to switch between the logs available for the deployment:
| Log file | What it contains |
|---|---|
odoo.log | Runtime activity of the running instance: HTTP requests, errors, cron jobs, tracebacks |
install.log | Output of the module installation that created the deployment |
update.log | Output of the module update run on each new deployment of existing code |
tests.log | Output of the test run, when tests are enabled for the branch |
requirements.log | Output of the pip install of your repository's requirements.txt, if you have one |
When a deployment fails
A failed deployment shows a one-sentence reason directly on its card in the Deployments tab, next to a See the log link. The link opens the log that shows the failure, already selected, so you do not have to look for it among the log files.
The reason names what went wrong and, when possible, where:
| What you see | What to do |
|---|---|
| A Python package is not installed | Add it to the requirements.txt at the root of your repository. See Install Python Packages |
The packages in requirements.txt could not be installed | Open requirements.log: pip says which package failed and why |
| Modules depend on modules that are not available | Add the missing modules to your repository, or fix the depends list in the manifest |
| A data file could not be loaded | Fix the XML or CSV file named in the message, at the line given |
| Your code raised an error | Open the file and line named in the message. The log has the full traceback |
| The database refused a change | Usually a new constraint or required field that existing records do not satisfy |
| Tests failed | Open tests.log to see which tests failed |
| A submodule or the repository could not be read | Check the deploy key and, for private submodules, Private submodules |
When the failure does not match a known cause, the message says which step failed and the link still opens the right log.
The message only ever contains module names, file paths inside your repository, line numbers and error types. The content of your data and of error messages stays in the logs.
A failed update never leaves production broken: the previous version is restored automatically, and the reason tells you what to fix before deploying again.
Turn the failure reason off
The reason is shown by default. A project admin can hide it for a project: open the project's Settings tab and turn off Failure reason on builds. Failed deployments then only show their status, and the logs remain available as before.
Filter and refresh
- Start date / End date: narrow the view to a specific time range. Click Clear dates to remove the filter and return to the full view.
- Refresh logs: fetch the latest lines. The "Last updated at" indicator shows when the view was last refreshed.
- Scroll up to load earlier lines; newer lines continue to load as the deployment produces them.
Build and deployment logs are stored durably, so they remain available after the deployment has finished, and even after it is later removed.
Tips for reading logs
- Look for tracebacks. Python errors appear as multi-line tracebacks ending with the exception type and message. Search for
Tracebackto jump to them. - Focus on the right severity. Odoo logs at
DEBUG,INFO,WARNING,ERROR, andCRITICAL. Scan forERRORandCRITICALfirst. - Deployment failed? Start from the reason shown on the failed deployment and follow its See the log link (see When a deployment fails). Otherwise open the failed deployment's Logs tab and select the build/install log. Module XML/parse errors, missing fields, and failed migrations surface there.
- Runtime 500 error or broken view? Select the Odoo server log and check the entries around the time of the error.
- Module fails on a missing Python library? Select
requirements.log. It shows whether pip installed your dependencies and, if not, why. See Install Python Packages. - A cron / scheduled action misbehaving? Its errors are logged in the server log at
ERRORlevel.