Instance health
Every day the server checks each instance for the things that go quietly wrong between releases: a database that renders its PDF reports through the public address and gets refused by its own firewall, a web address without a scheme, a container that exited, a web server site that no longer matches the configuration, a certificate close to expiry, an image missing a package a module needs. The result is a report per instance on its Health tab, with a card on its overview.
What is checked
| Check | What it looks at | Auto repair |
|---|---|---|
| Report address | Every database's report.url is http://127.0.0.1:8069, the Odoo server inside the instance's own container, so PDF reports render inside the instance rather than through the public address and the firewall | Sets it |
| Web address | Every database's web.base.url is a complete address on one of the instance's names | Sets it to the main name |
| Container | The container exists and runs | Starts a stopped one; an instance never installed needs the install |
| Web server site | The site is present, enabled and the one the configuration generates | Rebuilds the site and reloads |
| Certificate | Present, valid, more than two weeks from expiry, the kind the SSL options ask for, covering every name | Requests one as the SSL options say |
| Image packages | The image the container runs carries every package the configuration and the add-ons need | Rebuilds the image and recreates the container |
| Pending changes | The instance runs the configuration it stores | Queues the action the change needs: an apply, an image build, a certificate request or a module install |
| Reachability | The uptime probe reaches the instance. Without a result yet the row reads n/a and says why: a development instance, no host name, a server update in the last few minutes, a probe that has not run since the API started, the instance's own firewall refusing the probe, or failures not yet enough to call an outage | Restarts the container |
| Odoo build | The image is not further behind the newest build than the server's threshold. A build that cannot be read, or no newest build to compare with, is skipped with the reason rather than called current | Builds a fresh image and activates it |
| Backups | Backups are on for a production instance, and one of the instance's enabled backup providers holds a backup from the last seven days, as the Backup tab's Latest backups lists them. A backup that failed after the newest one is an error, a run of the server-wide schedule included; so is an instance backed up on a schedule with no successful backup for longer than its schedule plus a day. See Scheduled backups | Runs a backup now |
| Backup encryption | On an instance that encrypts its backups: the server has an active backup key, the license carries backup encryption, and the server holds the key. Encryption switched off when the instance arrived on a server without a key is a warning until it is on again | None: a key is created or imported on Backup storage > Encryption |
| Stored credentials | Every password, key and token the instance stores can be read on this server. Each one that cannot is its own warning, naming it and where to enter it again (see Credentials this server cannot read) | Removes the instance's own mail password when that is the one that cannot be read; none for the others |
| Tuning | At least two workers (one worker freezes the instance when a PDF is rendered), and the container ceiling the workload's workers, cron threads and websocket worker need fits what the host has left after a reserve for the system, PostgreSQL, the management services and the other instances; the finding gives that ceiling, what is configured and where the memory goes, in GiB as the Workload card shows them | Recalculates Auto from the workload and applies, when that would change something; by hand when even the two workers of the floor do not fit |
| License | The license covers what the instance is set up to use, and the instance is within the license's limits: its databases, and its custom modules as installed in its fullest database or as its git modules, whichever is more | None: a license or a setting is your decision |
| Subscription | On an Enterprise instance, every database carries its Odoo subscription code and an expiry more than 30 days away. No code and no date yet are warnings; an expired subscription is an error. Community instances are skipped | None: renewing is between you and Odoo |
| Scheduled actions | No active scheduled action of any database is a day or more behind its schedule. An action Odoo will never run again (one with no runs left) does not count. When no scheduled action of a database ran in the last day, Odoo's scheduler is not running them, and that is an error. When others still run, the ones behind are a warning that names up to five of them and when each was due: look at them in Odoo under Settings > Technical > Scheduled Actions. Skipped where the tuning gives the instance no cron thread | For the error, restarts the container, which starts the scheduler afresh; a warning has none, since a restart does not change a single action |
| Outgoing mail | No outgoing mail of the last seven days sits in Odoo's queue with an error. A warning says how many failed, when the last one did, and the mail server's answer to it, with any e-mail address in it masked. Skipped where the mail module is not installed | None: the cause is on the mail server or in Odoo's settings |
| Modules | Every module a database says is installed has its code in the image (the usual fault after a restore from elsewhere), and none is left between "to install" or "to upgrade" and done | Runs the pending install or upgrade again and restarts the instance; a missing module or one marked for removal is yours |
| GeoIP | On an instance with GeoIP on: the city database is in the instance's GeoIP directory, no older than 45 days, and a lookup with Odoo's own reader answers inside the container | Copies the databases from the GeoIP service again and restarts the instance |
| Custom modules | Every add-on module from a git remote that is installed in at least one database is at the head of its branch, as the server's git polling last listed it. A module installed in no database is left out, and the finding says how many were; a whole repository added without a module path is always judged. When the databases cannot be read, every module is judged and the finding says so. Skipped until the remote was listed | Queues the git update, only on an instance with automatic git updates on; elsewhere the Modules tab is the place |
| Odoo API access | The Odoo API rule on the Firewall tab is closed or limited to at most five addresses. Open to everyone, a whole country or a continent is a warning, as is a longer address list | None: closing a rule can cut an integration, so it stays your decision |
| Database manager access | The Database manager rule on the Firewall tab is closed or limited to at most five addresses. Open to everyone, a country or a continent is an error | None: your decision on the Firewall tab |
| Payment provider addresses | Every payment provider a Payments rule admits by name had its list of webhook addresses read in the last day. A list that cannot be read is a warning: the addresses read before stay in force until the provider moves its webhooks. n/a when no Payments rule names a provider | None: the list comes back by itself once the server reaches the provider |
| Ban notifications | With intrusion prevention on, someone is told when an address is banned: the recipients on the Threat protection page or, when those are empty, the server's own notification recipients (Append To on the E-mail tab of Configuration). With neither set the check warns; otherwise it says which list is used. Skipped when intrusion prevention is off | None: who is told is your decision |
Every finding says what was observed, what was expected and why it matters, in words meant for the person running the instance. Open a row on the Health tab to read the advice in full. The result of a health check job and its alert name each finding that wants attention with what it observed, and a support bundle carries every instance's latest report.
Credentials this server cannot read
Credentials are encrypted with keys that stay with the server that wrote them. An instance brought from another server, or a master database restored onto new hardware without its key ring, carries credentials this server cannot read. Where to enter each one again:
| Credential | Where to enter it again |
|---|---|
| A backup target's or restore source's password or key | The Backup or Restore tab |
| A git credential | The Modules tab |
| The DNS provider's token | The Certificate tab |
| The pre-authentication key | Save the Firewall tab's Pre-authentication settings again; visitors then sign in again |
| The instance's database password | Nothing to enter: the server generated it, and it reads again only on the server that wrote it |
| The instance's own mail password | Nothing to enter: it has no field in the console and nothing on the server uses it, so the auto repair removes it and the instance sends mail as before |
Running and repairing
The daily job is Instance health check on the Maintenance page, at 05:30 UTC by default; it reports and changes nothing. Check now on the Health tab runs the checks for one instance and replaces its report.
Auto repair puts right every finding marked auto and runs the checks again, so the report shows what the repair achieved. A finding marked by hand needs a decision only you can take, and its advice says which. A single finding can be repaired on its own from the row's detail.
Remote or localagainst
pelmo$ ohm instance health --instance fanesRemote or localagainst
pelmo$ ohm instance health --instance fanes --checkRemote or localagainst
pelmo$ ohm instance health --instance fanes --repairThe command exits non-zero when the report carries an error, so it serves as a probe from a script.
A repair is a job
Each repair is queued and followed like every other change, and several of them queue further jobs: an image build, a certificate request, an apply. The Jobs tab shows them; the report is re-read when the repair job ends.
Alerts
Two alerting event types carry the report:
- Instance health degraded is raised when an instance's headline changes - from fine to something wanting attention, or from a warning to an error - and resolved when every check passes again. The recommended rule Instance health delivers it at warning, once a day while it lasts.
- Instance health report is the whole report, every run, at the informational severity. Nothing is sent until a rule asks for it; add one on that type and the daily report reaches whichever channel the rule names.