Instance Health Signals
Skysize watches the Odoo log and the container state of your production environment and turns a fixed set of known problems into health signals. Each signal has one of three levels: info, warning or issue. A signal tells you what happened, how often, and what usually fixes it.
Only production is watched. Staging and development environments are working copies where errors are expected, so nothing is collected there.
Health signals live in the Health tab of the project, and the dashboard points to them wherever the environment is shown. Only a signal that reaches the Issue level notifies the project's admins, once per episode, by email and/or in the dashboard as each of them chose. See Notifications.
Free Sandbox projects
Production is watched on every plan, but the details of health signals are part of paid plans. On a Free Sandbox project the Health tab shows how many signals are open and at which level, and the dots on the tab, the project card and the production row stay visible. What each signal is about, its log excerpt and the usual fix are shown once the project is on a paid plan or a trial. Free Sandbox projects have no health banner, cannot acknowledge or mute signals, and their admins are not notified about health issues.
Upgrading reveals the signals already collected: nothing has to be detected again.
Where to find them
- Health tab on the project page, right after Branches. The tab carries a small dot in the colour of the worst open signal: red for an issue, amber for a warning, blue for an info. No dot means nothing is open.
- Project card in the project list and the production row in the Branches tab show the same dot.
- Production environment page and the monitoring area of a production build show a short strip listing the open warnings and issues, with a link to the Health tab.
- A project banner appears when at least one issue is open, so you cannot miss it.
The Health tab shows one section per production environment. Each row has the level, the title of the signal, the element concerned (the name of a scheduled action, for example), how many times it happened and when it was first and last seen. Open a row to read what the signal means, the usual fix, the last matching log line and, with the developer or admin role, the recent occurrences.
If the project has no production environment deployed yet, the tab explains that health signals are collected once production is deployed.
What is watched
| Signal | What it means | Usual fix |
|---|---|---|
| Default admin password still in use | The administrator account of your production database still has the default password admin. Odoo shows the same warning when that user logs in. Anyone who reaches the login page gets full access to your data. Always reported at the highest level. | Change the password in Odoo under My Profile > Account Security and enable two-factor authentication. The signal clears within an hour. |
| Scheduled action deactivated by Odoo | Odoo turned a scheduled action off after 5 failures over 7 days. It will not run again until someone re-enables it. | Fix the cause, then re-enable the action under Settings > Technical > Scheduled Actions in Odoo. |
| Scheduled action failing | A scheduled action raised an error while running. | Check the server log around the failure and fix the cause before Odoo deactivates the action. |
| Scheduled action timing out | A scheduled action ran longer than the time limit and was cut off. | Make the action faster, or raise the time limit (see Workers and Time Limits). |
| Scheduled actions skipped | Scheduled actions are not running because a module is stuck in the "to install" or "to upgrade" state. | Finish or cancel the pending installation or upgrade in Odoo. |
| HTTP worker killed on the time limit | A web request ran longer than allowed and its worker was stopped. Users see an error or a blank page. | Optimise the slow operation, or raise the request time limit in the project settings. |
| Cron worker killed on the time limit | The worker running scheduled actions was stopped on the time limit. | Same as above: make the action faster or raise the time limit. |
| Worker memory limit reached | A worker exceeded its soft memory limit and was restarted after finishing its request. Informational unless it repeats often. | Look for a memory-hungry request or report, or give the environment more memory. |
| Live chat worker memory limit reached | The worker serving live chat and real-time notifications was restarted on its memory limit. | Same as above. |
| Hard memory limit reached | A worker went over the hard memory limit and was stopped immediately, interrupting the current request. | Find the operation that consumes the memory, or raise the plan memory. |
| Container killed for exceeding its memory | The whole Odoo container went over the memory of your plan and was stopped, then restarted. | Raise the plan memory or reduce the number of workers. |
| Container restarting in a loop | Odoo keeps stopping shortly after it starts. | Read the runtime log: usually a broken module, a missing dependency or a configuration error. |
| Request errors | Requests end in a traceback. The count tells you how often. | Read the last excerpt and the runtime log to find the failing module or view. |
| Many failed logins | An unusual number of login attempts failed in a short time. Possible brute force. | Enable two-factor authentication and review the users and their passwords. |
| Database contention | Deadlocks, serialization failures or exhausted connection slots. Odoo retries, but users experience slowness or errors. | Look for long transactions and heavy scheduled actions running during business hours. |
| Attachment files missing | Odoo refers to files that are not in the filestore. Typical after an import made without the filestore. | Restore from a backup that includes the filestore (see Import an Existing Odoo Backup). |
| Outgoing mail failing | Odoo cannot send e-mail through the configured outgoing server. | Check the outgoing mail server settings and credentials in Odoo. |
How levels work
Each signal starts at a base level. When the same problem repeats inside its window, the signal escalates to warning and then to issue. The window is 24 hours for most signals and 1 hour for the fast-moving ones, such as request errors and failed logins.
A signal resolves on its own when the problem stops repeating for the length of its window. Two signals are exceptions because only you can fix them: Scheduled action deactivated by Odoo stays open until the action is active again, and Default admin password still in use stays open until the password is changed.
Resolved signals of the last 30 days stay available in the Health tab under Show resolved.
Acknowledge and mute
Two actions let you keep the Health tab meaningful:
- Acknowledge tells the platform that you have seen the signal. Its dot and its place in the badges disappear, and the signal stays listed with the name of the person who acknowledged it. If the level rises afterwards, the signal asks for attention again.
- Mute hides the signal for 1 day, 1 week or 30 days. A muted signal never counts toward the dots and the banner. Muted signals are grouped under a Muted toggle in the tab, and you can unmute them at any time.
Both actions need the developer or admin role on the project.
What is stored
Health signals are built from patterns in the Odoo log and from the container state. The default password check runs once an hour on the server that hosts your database: it compares the stored password hash of the administrator account with the hash of admin. It never attempts a login, and no password or hash leaves the server. For each occurrence, only the matching log line is kept, truncated to 300 characters, and it is deleted after 30 days. Full logs remain available as described in View Logs.